December 8, 2016 // By Paul Grizzaffi
This is the first in a series of blog posts regarding the information you may need to consider when beginning an automation initiative and choosing an automation technology for your testing needs.
There will be no pot of gold at the end; there will be no decision matrix crowning the one, true tool for a given set of criteria. What there will be is a series of considerations, ones that I try to take into account when I’m beginning a new automation initiative. Where applicable, I will describe instances from my own career when I was successful because I did consider these things; I’ll also include instances where ignoring these things caused me to be…less than successful.
First things first…a definition.
When I hear automation discussed, the conversation typically revolves around test cases and tools. How many of us have asked or been asked questions like these:
“What tool do you use?”
“How much of your regression is automated?”
“What’s the best tool for Technology X?”
In the appropriate context, these are valid questions but I consider them related to specific implementations of automation, not the general concept of automation.
Over my career, I’ve refined my definition of automation; most recently I use the following:
automation is the judicious application of technology to help humans do their jobs.
In our case, the humans are testers and their jobs are testing and testing-related tasks. Notice I don’t mention test cases, tools, scripts, or any specific technology. Why should we shackle ourselves to an automation definition based strictly on test cases? Using a broad definition of automation gives us a wide range of opportunities with which to provide value in our testing organizations. Taking advantage of this range allows us to think of automation as a force multiplier that helps us be more effective, efficient, etc.
As a point of comparison, a small set of scripts that run on every build may pay huge dividends for one organization by allowing its teams to quickly check for newly introduced, high-impact issues. For another organization, that kind of suite may be equally valuable, but is of lesser value when compared to creating scripts to generate product test data. Using the above definition of automation allows us to discuss the value of each of those two opportunities, compare their respective values, and then prioritize our efforts based on those values.
The remainder of the series will use the definition above as a frame of reference and aims to help us provide value with our automation initiatives.
Paul Grizzaffi is a Principal Consultant at Magenic. This post was republished from his personal blog and can be found here.