What’s a Tester without a QA Team?


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.


About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.