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 were 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 there 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 specialists is just a test specialist using tools to test a 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 inherent part of product development. This view is inspired by TDD, ATDD and BDD (where the "development" is a 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 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 ideas I describe are not universally right or wrong, and they applicability depends heavily on the context. I think I also should do a better job on defining a context before describing ideas.

The other takeaway for me is that viewpoint of test automation as a part of development seems to have 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 do discuss an implicit assumption we usually make and how right or wrong they may be.

Please stay tuned,


Popular posts from this blog

Test automation framework architecture. Part 2.2 - Two-layered architecture

Test automation framework architecture. Part 2.1 - Layered architecture example

Test automation framework architecture. Part 2 - Layered architecture