After decades of talking about test automation, the agile movement suddenly seems to be taking it seriously. You might be wondering what all the buzz is about. Is this something software developers didn’t realize during the waterfall era? How did the waterfall teams survive without automation?
I’d like to talk about why test tooling is suddenly so critical, when teams should think of automating, and how to bring the change.
Why Do We Need Test Automation?
Test automation as a concept is independent of method. There were many waterfall teams that automated checking and evaluation of their test processes; the question is, why is it so popular now?
My personal view is that, apart from many things that came together in the last ten years, the main driver is the frequent release required by agile. Now that agile methodology has become widespread, teams need to fit the entire plan/build/test/deploy window into two weeks—and two months of test/fix/retest won’t cut it. Speed, accuracy, and quality became key factors driving agility in the organization.
When Should We Embrace Test Automation?
You should not adopt automation “just because” Amazon, Facebook, or some popular company is doing it. First, find out the need. You might ask, When there are benefits across the board with cost, speed, quality, and accuracy, why should we delay? Well, these benefits must be understood before introducing test automation.
You might want to actually make a spreadsheet clearly quantifying the benefits. Here’s a sample spreadsheet to help you think about goals and possibilities with tools:
Don’t get carried away too much with the above numbers. Results vary for different teams and circumstances. In fact, I have come across situations where test automation could do more harm than good.
Consequently, you should quantify your process to enforce the idea of data-driven thinking and avoid emotional decisions. If you cannot quantify the benefits, don’t waste time.