In this tongue-in-cheek talk I will show how easy it is to disrupt or utterly ruin a test automation project. By describing seven proven methods to reach this end, I intend to give managers, testers and automators the means to recognize early on if their automation is in danger. And by ‘warning’ against possible defences I will actually give them the tools to counter and solve such issues.
Target Audience: testers, test automators, test managers
At most conferences, somebody will show you in talks or tutorials how to get started with test automation or how to improve it. Nobody ever tells you how to kill it!
Lots of people succeed accidentally, but in this talk I will disclose proven methods to do it deliberately. Even more I will reveal how this could be prevented (using test automation patterns) so that you can plan your countermeasures!
1) A sure method for success is to let a lone champion keep all important knowledge for himself or herself. As soon as he or she is gone (and of course that can be quite easily arranged!) your automation will be dead in its tracks.
2) Another proven way is to develop all your scripts or keywords exclusively within a specific tool. In this case, you just need to scrap the tool (I can suggest some good reasons to do that) and again your automation is done for.
3) A very successful method is to ignore good programming practices and for instance automate the test cases using capture-replay (in modern tools it may have a more appealing name!). In this case, you just have to wait until the next few releases of your application for automation to become shelf ware.
4) Also, quite successful is to automate the test cases exactly as they are performed manually (complicated tests that may even depend on each other).
5) For managers, the best method is definitely to feign support, but not really give it. In this way test automators will spend all their energy trying to fit automation work around other work, trying to get resources, information or simply help from specialists and progress on automation will soon come to a crawl. It will not take long for management to conclude that test automation was not a good idea!
6) Managers also have other possibilities, for instance by setting quite impossible goals. In this way, it’s easy, to kill it off later because it failed to reach them.
7) Finally, the best method for developers is to continually change the objects to be driven in the application to be tested. In .net for instance, with just ‘minimal’ changes to the object hierarchy, you can immediately cripple the automation. In other environments, you may need more subtle changes, but this surely isn’t rocket science for a good developer! Just remember to make maintenance of the automated tests as difficult as possible.