Guaranteed Methods to Ruin Your Test Automation
In most conferences there are talks or tutorials about how to start or improve test automation. One learns lots of possible best practices, but generally, little time is spent on explaining why they are best practices! Personally, I find it easier to adopt a new methodology if I understand why it is better.
I started to consider what can ruin a test automation effort. Having worked for more than fifteen years on test automation, and after collaborating with Dorothy Graham on the test automation patterns wiki, a collection of solutions developed by experienced practitioners to solve common test automation issues, I came up with seven methods that can really destroy your test automation.
I noticed that there are two main ways. I called the first ones guillotine methods because they are final: One develops test automation for some time and then just kills it off.
The second ones are sneakier, and I call them boiled-frog methods. There’s a fable about a frog in a pot. When you first put a frog in a big pot filled with water, the frog finds it great and swims happily around. Then you start heating the pot very, very slowly, so that the frog doesn’t notice the changes in temperature until it’s already cooked. With test automation, it works the same way: In the beginning everything looks great, but slowly it becomes more burdensome to keep the existing tests running—and almost impossible to develop new ones. Just like in the fable, people notice only when it’s already too late.
A good example of a guillotine method is one I call “Fire Atlas.” In Greek mythology, Atlas was a Titan holding the world on his back. Likewise, in test automation, Atlas alone develops, runs, and maintains test automation—this one person is test automation. It’s easy to recognize that by firing Atlas, one can immediately destroy test automation.
One example of a boiled-frog method is “Feigned Support.” This is perfect for managers: They only have to affirm over and over again how much they support test automation. But when an automator dares to ask for some kind of support, the answer is always that just now, it’s not possible! In this way automators try to get something done without help, without resources, and possibly by working only part-time on test automation. This makes it easy for the manager to realize that test automation just isn’t right for the company.
Another example is “Primitive Programming Practices,” which is the method of choice for testers turned automators. They mostly have no idea of best practices and write testware that is not reusable or maintainable. It cannot be a surprise when such creations surely turn into shelfware.
The most effective defenses can be found in the test automation patterns, including designating deputies, documenting testware, good programming practices, designing for reuse, keeping things simple, and setting standards. So be sure to steer clear of these practices if you want to ruin your test automation!
Seretta Gamba is presenting the session 7 Proven Ways to Ruin Your Test Automation at STARWEST 2018, September 30–October 5 in Anaheim, California.
