Two different views on Test Automation

-
I have published several posts with the aim to deliver one message - sometimes it is more efficient (fast and convenient) to change the application under test (make it more testable or eliminate the need for testing at all) then invent or employ complicated test automation techniques to check the same functionality. Even though there was a lot of misunderstanding caused by badly forming those posts, I still think I stroke something deeper.

For instance, this twitter post made me think that we speak two different languages:


Now it started to seem to me that there're two different views on what test automation is. First, probably prevailing point of view is that test automation is a part of ages-old traditional QA process, where test automation specialist is just a test specialist using tools to test software. There's nothing wrong with this model, and it is very applicable to some context. However, it was not the viewpoint I wanted to present.


So second, probably less popular viewpoint, is that test automation is an inherent part of product development. This view is inspired by TDD, ATDD and BDD (where the "development" is the main word) practices. I was claiming that this approach is efficient. However, it would be better if first, we identify what is efficiency in the first place.

I made an attempt to describe what I mean by efficient test automation in this blog post. Most of my ideas are aimed to achieve this kind of efficiency. However, efficiency, in another context, may mean something different.

If we define efficient as "catching as many issues as possible in a given amount of time", my model well probably be less applicable. If we define efficient as "assuring some predefined bugs containment level" my model will not work at all. This is something I also mentioned the other day in that post.

The key takeaway (for me) is that the ideas I describe are not universally right or wrong, and their applicability depends heavily on the context. I think I also should do a better job of defining a context before describing ideas.

The other takeaway for me is that the viewpoint of test automation as a part of development seems to have a surprisingly low level of support, even in the contexts where it is perfectly applicable. To discuss that I am going to deliver another talk (and follow up blog post). In this post, I will try to discuss an implicit assumption we usually make and how right or wrong they may be.

Please stay tuned,
AQAGuy.

Comments

Post a Comment

Popular posts from this blog

Test automation framework architecture. Part 2.1 - Layered architecture example

-
Image
Let's consider an example of what Layered (Tiered) architecture may look like for a test automation framework. As a system under test, we're going to use this simple and neat "Todo list" application. First, let's do a brief analysis of the application. From my brief exploration I came up with the following checklist: Area/Group Things to check Comments Todos CRUD 1 Create item Basic scenario, UI-level case 1.1 Create an item with the same name The case is not valid. There's no validation for that - nothing to check really. 1.2 Create an item with an empty/not valid/malicious name While it would be a nice thing to test manually, from test automation standpoint I would expect this to be filtered on service or repository level, so either integration or unit test . 2 Mark item complete Basic scenario, UI-level case 2.1 Un-mark item complete Basic scenario, UI-level case 3 Delete item Basic scenario, UI-level case 3.1 Delete item
Read more

Test automation framework architecture. Part 2 - Layered architecture

-
Image
Probably the most popular architecture pattern used for test automation frameworks (TAF) is layered architecture. This pattern is so well known that on job interviews for some companies when they ask you about TAF architecture you are supposed to describe this one. If you don't - they think you know nothing about the architecture altogether. I suggest you first read a brilliant description of the pattern at the O'Reilly web page , cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution. Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer , business-layer and core layer , but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above). The rough
Read more

Efficient test automation - Secret #1 | Test Club

-
Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more