by Lisa Crispin and Janet Gregory

When a tester joins an agile team, she leaves her Test or QA team behind. Often, her old QA team is disbanded altogether. Without the support of a QA team, she might feel abandoned, especially if she now reports to a development manager. She’s in danger of becoming isolated, having lost the phased and gated process that guided her old team. She may feel pushed to the sidelines and like she’s lost any control over quality.

Preparing for Tester Success
Organizations that want their agile transition to stick must make sure that feeling of isolation doesn’t happen. Like everyone else on a new agile team, testers need the right training and support to succeed. They need to learn how to collaborate with programmers, database experts, business stakeholders, and people they might not have had any contact with before. They may need new technical skills as well. Well-functioning agile development teams make sure to embrace testers, and provide the infrastructure to help them succeed.

The Whole Team Approach
In successful agile development teams, every team member takes responsibility for quality. This means that although testers bring special expertise and a unique viewpoint to the team, they are not the only ones responsible for testing or for the quality of the product. The other team members all play a part in testing, and testers can ask other team members for help. The good news for a tester who’s now on a development team is that she expands her influence – she’s involved right from the beginning of each project. She’s part of the requirements elaboration and iteration planning. She collaborates with the whole team throughout the iteration.  This collaboration starts when she works with the customer or product owner to define acceptance (customer) tests, and continues when she reviews story tests with the programmers and asks for input to help guide development.

This whole team approach is very powerful. For example, when part of the application is difficult to test, we can ask the team to consider the problem. Since coding and testing are no longer separate activities, developers can find design approaches that enhance testability. If  it takes too long to find out whether a code change broke existing functionality, the build master may be able to help by speeding up the continuous integration process.

When teams follow the whole-team approach, nobody feels siloed. Each person is an equally-valued member of the project team, and they all help each other along the way. We’ve met teams where the QA and development managers worked together before the agile transition to figure out how what their role would be and how they could best help their teams. As a result, testers had plenty of support to learn how they fit on the new agile team.

A “Whole Team” Example
When Lisa joined her first agile team, she had to let go of the notion that she was the judge of product quality. Instead, she had to learn how to help customers define quality and “doneness” criteria before coding was started. She joined discussions with programmers and the DBA where the stakeholders gave examples of desired behavior. In the beginning, there were no automated regression tests, so everyone on the team did the manual tests each iteration. Everyone on the team committed to completing each story before the end of the iteration. If testing started to fall behind, Lisa asked for help, and everyone on the team performed testing tasks.

The system administrator helped put a continuous integration and build process in place, providing quick feedback from regression tests. Several months later, the team enjoyed adequate automated regression testing, with more time free to collaborate with business experts and learn more about the domain. The team could focus on new development instead of fixing bugs, and testers had time to do important exploratory testing.

Resources for Implementing a Whole Team Approach
“It sounds great”, you say, “but we’re still working as siloed groups, how do we transition to this whole team approach?” We recommend to new agile teams that they bring in an experienced agile coach or hire experienced agile developers and/or testers to help overcome cultural and logistical barriers. The Scrum concept of a self-organizing team helps; the team can commit to delivering the best software possible, and then experiment with practices that help achieve that goal. However, managers must give the team plenty of time to learn, and provide training in skills that the team is lacking. For example, the team may need formal training in test-driven development and acceptance test-driven development.

Hold team retrospectives each iteration – make sure everyone on the new integrated team participates and feels safe to raise issues. If you’re new to retrospectives, consider bringing in an experienced facilitator to get started. Books such as Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson, and Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising will give you ideas on how to run retrospectives and introduce changes..

Testing Community of Practice
Another source of support a tester has is her testing community within her organization.  Rather than eliminating the QA Manager role and completely disbanding the QA team, we suggest that organizations create communities of practice. The QA or test manager, who previously managed the test team,  becomes a practice manager, devoted to making sure testers get the support and training they need, and can get together to share testing innovations and experiences.

This  practice leader can help testers find new tools to coordinate integration level testing and work to create viable test labs. He also provides a very important role supporting a tester’s learning efforts through training, encouraging inter-project interactions, and maybe even fuelling the testers’ passion.

An Example of Building Community
Janet has had really good success with test teams building their own communities focusing on learning and sharing. In one large team (40 testers, 4 QA managers and a director), the testers reported to the QA Managers for performance reviews, training, and support. The he day to day operational management of the testers, programmers and other development roles was accomplished within each team. Performance reviews were always done by the QA managers, with input from their project teams.  The testers held weekly “lunch and learns”, team building exercises, and built a real sense of community. There really wasn't any friction between this 'community' and the project teams. They worked very closely together. If one tester wasn't working well on one team, the QA managers would work with the teams to solve the problems.

Resources for Building a Community of Practice (CoP)
When Lisa wanted to build a testing CoP in an organization with 25 Scrum teams, she looked around at other successful testing communities. One good example is the Weekend Testers (www.weekendtesting.com), a group of testers who get together for two-hour weekend testing and discussion sessions using a group chat and online facilitator. Another inspiration is the Software Testing Club (www.softwaretestingclub.com), an online community for software testers with a forum, a community magazine, and other resources. The January issue of Software Test and Performance magazine (www.stpcollaborative.com/magazine) has interviews of Parimala Shankarariah, who helped start Weekend Testers, and Rosie Sherry, who founded the Software Testing Club. On-line user groups such as the agile-testing@yahoogroups.com is a great place to ask questions or share ideas with other participants who are interested in agile testing.

Lisa took advantage of the company’s new Confluence wiki to set up a testing community space, with a forum, links to individual testers’ blogs, and a schedule of events. Testers and programmers volunteered to give hour-long demos and classes on testing and test automation at least once per month. These were well-attended, and the surprise was that many programmers attended as well.

Sharing Knowledge
When testers have that sense of community, they want to share their testing experiences with testers from other project teams. This creates shared common knowledge across the teams.  If one team finds a tool they think can help another team, they share their innovations to save time and energy.  This kind of respective knowledge sharing is good for the organization. Testers get the support they need and plenty of help solving the toughest testing issues.

Once a tester no longer thinks of herself as isolated, or a victim of process, but instead as someone as with power to help the team, she can start to take charge of her own development.  As part of a learning organization, she will be encouraged to read articles and professional blogs, write articles of her own, present successful team initiatives to other teams, participate in larger community organizations such as local quality or agile groups, attend conferences or maybe even present at one. Participating in a testing community within the organization, as well as larger testing and development communities on local, national and international levels, helps us and our development teams continually find ways to work better.

Expanding Your Horizons
As you can see, testers need never be alone, even if they don’t belong to a separate QA team. They have a giant support group ready to help them if they reach out and find it. Even more importantly, testers bring their expertise to a development team where everyone, not only testers, is passionate about quality. It takes courage to get out of your comfort zone and team up with developers for the first time. You may need to learn new skills to help customers specify their quality criteria for each new piece of functionality.

Open your mind to the new possibilities. Team up with developers to solve testing problems in new ways. Maintain a strong connection to your tester community to exchange experiences and good practices. Take advantage of all the resources on the internet, in publications, in local and online user groups, and keep learning. You may find you enjoy your job even more than when you were part of a QA team.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview