Having someone on your test team with automation knowledge can be helpful. However, spreading that knowledge across the team can improve the individual testers, the project, and the test team as a whole. In this article, Bob Jones explains why his team first tried whole-team test automation and offers some tips for implementing it on your team.
Like many test automators, I spent years developing my automation skills. I worked with teams of testers who did not have coding experience, so my skills were special. This was good for me, but I don’t think it is good for the profession of software testing. Now, I devote my time making these special skills ordinary.
Traditional testing did not really do much to compel testers to grow technically. Too much emphasis was placed on process and manual test execution. It was often hard to figure out how to use automators effectively. Fortunately, the demands of agile testing changed that. Agile requires groups of people to work together as peers and to trust each other’s skills. It requires technical testers.
What We Are Trying to Accomplish
A quick look at testing blogs and articles suggests that others share the idea that agile testers benefit from technical training. For example, in “ Learning for Agile Testers ” in the September/October 2011 issue of Better Software magazine, Lisa Crispin and Janet Gregory write about technical training for agile testers. If we testers do not look out for ourselves and develop a high standard of what a professional tester should be, we risk becoming ineffective and outdated very easily. The investment to grow a whole-team test automation program is significant. Reasons for doing this affect the tester, the project, and the test team.
For the Tester
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. To make matters worse, 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.
The more technical a tester is, the more tools he has in his toolkit and the better he will adapt to new situations, ranging from new technologies with services testing to fundamental changes in how software testing is done. Adapt or die.
Never forget, agile testers are developers. As members of a software development team, I think it is important that 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.
For the Project
In agile development, rapid development of automated tests is critical. There are a lot of short-cycle sprints, and no one wants to retest the previous sprints’ work to make sure it doesn’t break. While we still struggle with keeping up with automation during sprint work, it is the job of the testers and the Scrum teams to do what is best for the project. This may mean aggressively developing regression tests or other efficient test tools throughout the project.
It isn’t acceptable for one project to have good coverage just because it happens to have the good automator. All projects deserve technically skilled testers.
For the Test Team
On many test teams, the full team is not exposed to existing automated tests. This lack of exposure leads both to misunderstandings about what the tests do and to poor test design. When the team members are not intimately familiar with their tests, they make assumptions. And, the more distant a team is from the tests, the more this becomes a problem.
It is easy to assume that when we have tests for an application, we don’t need to worry about the actual coverage. Some tests might have names that suggest greater test coverage than they actually provide, and if we don’t open the test and read the code, we will never know. Unsupported