About every four months, Shrini Kulkarni convinces me to drop the term “Test Automation” from my vocabulary. After all, testing is a creative, thinking process. We can automate some steps of what we are doing, speeding up repetitive work – but those don’t turn out to be the investigative, critical thinking steps(*).
Still, I want to use a word to describe when I use automation to go faster. I use awkward terms like “automating the repetitive steps” or “build verification tests” for a few months, until I end up calling it test automation. Then Shrini emails me, and the cycle repeats.
Since I am on the down-stroke of one of those cycles, I thought it would be appropriate to link to an old paper of Brian Marick’s:
I want to automate as many tests as I can. I’m not comfortable running a test only once. What if a programmer then changes the code and introduces a bug? What if I don’t catch that bug because I didn’t rerun the test after the change? Wouldn’t I feel horrible?
Well, yes, but I’m not paid to feel comfortable rather than horrible. I’m paid to be cost effective. It took me a long time, but I finally realized that I was over-automating, that only some of the tests I created should be automated. Some of the tests I was automating not only did not find bugs when they were rerun, they had no significant prospect of doing so. Automating them was not a rational decision.
The question, then, is how to make a rational decision. When I take a job as a contract tester, I typically design a series of tests for some product feature. For each of them, I need to decide whether that particular test should be automated. This paper describes how I think about the trade offs.
The paper is “When Should A Test Be Automated?” – and it is available on the web.
Now, that isn’t exactly my philosophy, but I think it’s good readin’.
Speaking of good readin’; if you are doing test automation by writing code in a true programming language to hit a GUI, you might enjoy this classic by Michael Hunter. (If you are not, it’s still an interesting read, but everything after about page 12 is very specific about writing code libraries for application ‘driving’cripting.)
And now, Shrini, I’m back on the up cycle. Really. I promise.
(*) – It doesn’t help that a lot of “test automation”, especially in the 1990’s, were snake oil products, designed by marketeers, to show how testing could be “sped up” with massive ROI numbers. I can’t tell you how many boxes of GUI test automation software I have seen sitting, unused, on shelves. Lots – and even more than that are the stories I’ve heard from colleagues.
When I talk about test automation, that’s not what I mean – see philosophy I for a better description.