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.
Follow @aqaguy
For instance, this twitter post made me think that we speak two different languages:
That's like asking a pharma company to self-certify that their drugs are safe without any independent approval! #softwaretesting #CIO— Ayush Trivedi (@ayushtrivedi) 4 September 2017
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.
Follow @aqaguy
Comments
Post a Comment