If you thinking that this seems like a lot of work, you are right. It takes an effort. So, why would we invest in this idea?
- In agile development, rapid development of automated tests is critical. While we still struggle with keeping up with automation during sprint work, the option is always there for the testers and the scrum teams to do what is best for the project. This may mean aggressively developing regression tests throughout the project. It is not acceptable for one project to have good coverage just because they happen to have the good automator – all projects deserve technically skilled testers.
- At many companies, automated tests are developed, executed, and owned by a separate group within the test team. This creates a two-tiered test team. It creates a situation where the most technical members become more technical because they have the most practice and the least technical members have no opportunities to grow their skills. That sucks if you not technical and have no opportunity to grow.
- The more technical a tester is, the more tools the tester has in his toolkit, and the better the tester will adapt to new situations. The new and changing situations range from new technologies such as services testing to a fundamental change in how software testing is done. Adapt or die.
- Agile testers are developers. As members of a software development team, everyone should know how to code. It is good for your self esteem, and it helps you gain and keep the respect of the other developers on your team.
- Build or select a suitable test framework and implementation methodology, and develop a transparent approach to testing. For this, we chose HP’s BPT framework with QTP as the underlying automation engine. Using BPT and our “Archetype” implementation technique, all members work together and take advantage previous work and each other’s skills. With a good framework, new team members can build tests, and experienced automators have opportunities to work on challenging work.
- Good recruiting. Regular, run-of-the-mill “QAs” are not right people for the team. Be prepared for this to take a long time. Because of the history of testing (a combination of “QA” process types and non-technical manual script runners), many good people stay away from testing jobs. My only advice here is to start with high standards, don’t let your standards drop, and keep hope. Great people are out there. And in my opinion, most recruiters will not be your friend. They will pressure you to take conventional candidates. Be aware of recruiters.
- Be prepared to train people . Some of the most obviously experienced candidates will take the most time. Many experienced automators do not work in a whole-team automation environment. As a result, they tend to build tests for themselves and not for the team. There is often “unlearning” that has to happen.
- Promote technical skills. Learn new programming languages and new technologies. This year when we studied Ruby together, we spent some time looking at Rails projects. By looking at and studying Rails, we accidentally learned about MVC frameworks.
- Devote enough time. In addition to the sprint work that we do (with or without other testers), we devote an hour each day to work together on automation. This way, we share ideas, learn from each other, set high expectations for each other, and continue to practice our art. There is a bonus with this approach when you are working on projects that are not interesting. If your project stinks, you can work with other team members on their automation needs. Everyone wins.