In the age of Agile, “automate everything” is a common mantra among software developers. Many teams have enthusiastically embraced the idea of test automation and moved quickly away from as much manual testing as possible. Test automation is often viewed as a way to cut back on labor costs, increase speed, and improve accuracy. But has our enthusiasm for automated testing clouded our ability to effectively and holistically evaluate the return on investment in test automation? Do the benefits truly outweigh the costs?
One disadvantage to test automation is the amount of developer time and skill required upfront to write the script for the automated test. While this is very often made up for in the time saved by the automation itself, it is easy to underestimate the upfront costs of test automation. Ultimately, a scenario likely will need to be tested many times over to justify spending the initial effort to automate it, so complex scenarios that are only tested a handful of times may not be profitable to automate.
A misconception surrounding test automation is that once the automation is written, it never has to be touched again. Of course, this is inaccurate – there are plenty of situations in which the system changes, requiring a change in the automation script. Just because an automation test fails, that does not mean there is necessarily a bug in the application, and this triage requires human consideration and experience. For example – did the test fail because it discovered an actual bug or is there something else at play, like a change in the requirements?
So should you embrace test automation? The answer, despite the disadvantages and misconceptions, is absolutely yes – but only in situations where the return on investment is positive. While test automation ultimately frees up testers from manual, scripted testing, it will never replace the need for human testers. In fact, one of the most exciting things about test automation is the way that it is opening the door for more exploratory testing on agile teams, promoting better end user advocacy and better software quality.
Interested in learning more about implementing test automation? Join Brad Schoening, Paul Holland, and Keith Klain of Doran Jones as they discuss their successes and failures which have led them to a balanced approach to test automation between developers’ unit tests and testers’ functional tests – this Friday! Sign up here.