October 15, 2019 // By Paul Grizzaffi
In 1998, the band The Gathering released their 5th studio album entitled How to Measure a Planet?. It was a drastic departure from their earlier doom-death records. In that way, they were not unlike other bands of the time such as Paradise Lost and Tiamat, though I preferred how the latter two bands transitioned. The title of this record, however, has always stuck with me as a thought around “yeah, how the hell do we do this thing?”.
Planetary measurements and metal aside, just last week I encountered a situation that I’ve been in several times and that reminded me of the name of that album: I was asked how long it will take to create X number of automated test scripts that would be based on existing test cases. This is a rather preposterous question. How could we possibly know if we’ve not looked at the test cases themselves? That’s like asking a product developer “how long will it take you to write X number of classes?”; I submit that this is an equally absurd question.
Developers are not asked questions like this because these kinds of questions make no sense in software development: each class performs different actions and contains different data, which means the creation of some classes will be more effort-intensive than other classes. It is the same with automation; some scripts will be more effort-intensive than others.
So why is this kind of question asked of automation developers? It’s because automation development isn’t always treated as a software development activity. Psst…it is software development so it must be treated as such. We are not absolved from our software development responsibilities even if we are using codeless or scriptless automation; as I said in this prior post, “Somewhere, under the hood, in that stack, there is some software”.
But, wait a minute, product developers are asked to give estimates all the time, why should automation developers be any different? In this sense, the automation developers are not different, but the questions being asked are not analogous. Product developers are not asked to estimate “how long will it take to develop a program?”; they are asked “how long will it take to develop this specific program?” or, more often, “how long will it take to develop features A, B, and C?”. What’s present in the typical question-to-developers is context; this kind of context is what’s missing from “how long it will take to create X number of automated test scripts?”.
Whether automating based on existing test cases is valuable or not is a business decision that must be made on a case by case basis. If this approach is something that we find appropriate for a given situation, we should certainly do it. But…contextless questions about how it will take to automate a set of something? Stop it, just stop it.