I’ve been telling QA professionals for at least 5 years that they need to learn test automation. I don’t mean a record and playback tool. I mean writing test code with the skill of a software developer.
Why? The most obvious reason is regression.
In an Agile project the development team is adding functionality in increments as the project progresses. As each increment is completed it needs to pass new and regression tests. It doesn’t take a genius to see that regression testing will eventually overwhelm the manual testing team. At that point the team can try to find additional testers or reduce the number of tests. But reducing the number of tests introduces risk.
The solution is automation. The automation tool can run regression on each build, ideally as part of the build cycle. This frees the test team to focus on the new functionality, the best return on the human investment.
The other reason is less obvious. People are creative and most tend to like expressing their creativity. Coming up with new tests is creative. Executing them isn’t. If your test plan is in the form of an automation script you’re focused on the satisfying creative work.
Conventional wisdom is that automation scripts can’t be written until the code is stable. In our most recent project we proved conventional wisdom wrong. In my next post I’ll go into some of the specific behaviors that made early automation possible. For now I’m asserting that it can be done, making a more satisfying and successful test effort.
Why not have separate manual and automation testers? Soon it will come down to economics. When a team can do all its testing with automation the manual testers will be a luxury. If you are a QA professional, you don’t want to wait for that to happen.