Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Integration of Testers into an Agile Project

The whole-team approach in agile development has provoked many organizations that have adopted agile development to disband their independent QA teams and send their testers to work with the project groups. While this sounds great, some organizations have found that it doesn’t work as expected. More than one organization has had most, if not all, of their testers quit when they found themselves on an agile development team with no idea what they should be doing.

Developers get training on pair programming, test-driven development, and other agile practices, while testers often seem to get no training at all. Many organizations fail to recognize that testers also need training on pair testing, working with incomplete and changing requirements, automation, and all of the other new skills that are required. It’s critical that testers receive training and coaching so that they can acquire the skills and understanding that will help them succeed, such as how to work with customers to write business-facing tests. Programmers also might need coaching to understand the importance of business-facing tests and the whole-team approach to writing and automating tests.

Janet has helped integrate several independent test teams into agile projects. She finds that it can take up to six months for most testers to start feeling confident about working with the new process.

The pairing of programmers and testers can only improve communication about the quality of the product. Developers often need to observe the behavior of the application on the tester’s workstation if that behavior can’t be reproduced in the development environment. Testers can sometimes sit down with the developer to reproduce a problem more easily and quickly than they can by trying to record the steps in a defect. This interaction reduces the time spent on non-oral communication.

Comments we’ve heard from testers on this subject include the following:

“Being closer to the development of the product makes me a better tester.”

“Going to lunch with developers builds a better team, one that wants and likes to work together.”

One major advantage of an integrated project team is that there’s only one budget and one schedule. There is no “testing” time to cut if all of the functionality is not finished. If there is no time to test a new feature, then there is no time to develop it in the first place. The whole-team approach to taking responsibility for quality is very powerful, as we point out throughout this book.

Lisa’s Story

I once joined an XP team that had been depending solely on unit-level testing and had never had anyone in a tester role before. Their customer wasn’t all that happy with the results, so they decided to hire a tester. While I attended daily stand-ups, I wasn’t allowed to talk about testing tasks. Testing time wasn’t included in story estimates, and testing tasks weren’t part of iteration planning. Stories were marked “done” as soon as coding tasks were complete.

After the team missed the release date, which was planned for after three two-week iterations, I asked the team’s coach to try the whole-team approach to testing. Testing tasks went up on the board along with coding tasks. Stories were no longer considered done until testing tasks were finished. Programmers took on testing tasks, and I was a full participant in daily stand-ups. The team had no more issues meeting the release plans they set.

—Lisa

Testers need to be full-fledged members of the development team, and testing tasks need to be given the same attention as other tasks. Again, the whole-team approach to testing goes a long way toward ensuring that testing tasks are completed by the end of each iteration and release. Be sure to use retrospectives to evaluate what testers need to integrate with their new agile team and what skills they might need to acquire. For example, testers might need more support from programmers, or from someone who’s an expert in a particular type of testing.

A smart approach to planning the organizational changes for agile development makes all the difference to a successful transition. Ask the QA and development managers to figure out their own roles in the new agile organization. Let them plan how they will help their testers and developers be productive on the new agile teams. Provide training in agile practices that the team doesn’t know. Make sure all of the teams can communicate with each other. Provide a framework that lets each team learn as it goes, and the teams will find a way to succeed.

Transitioning QA and Engineering Teams—Case Study

Christophe Louvion is a CTO and agile coach for high-profile Internet companies. He told us about one experience he had while helping his company implement agile development. As the agile coach, he wanted to truly implement agile development and avoid the common “small waterfall” mistake, where the developers spend a week writing code and the testers spend the next week testing it.

His company at the time was an organization of about 120 engineers, including the internal IT departments. Before transitioning to Scrum, the company was organized functionally. There were directors of QA and Engineering, and the idea of product-based teams was hard for management to accept. The managers of these teams struggled with the following question: “What is my job now?” Christophe turned this around on the managers and said: “You tell me.”

He worked with the Engineering and QA managers to help them figure out what their jobs would be in the new agile environment. Only when they were able to speak with one voice did they all go to the teams and explain their findings.

In the new agile organization, managers deal with specific domain knowledge, resources, prioritization, and problems that arise. The Engineering and QA managers work hand-in-hand on a daily basis to resolve these types of issues. Christophe and the two managers looked at what prevented testers from being productive in the first week of the two-week iteration and taught them how to help with design.

For the programmers, the question was “How do I make it so that the code is easy to test?” The engineers weren’t trained in continuous integration, because they were used to working in phased cycles. They needed lots of training in test-driven design, continuous integration, and other practices. Their managers ensured that they got this training.

Configuration management (CM) experts were brought in to help with the build process. The CM team is separate from Engineering and QA at the company, and it provides the framework for everything in the build process, including database objects, hardware, and configurations. Once the build process framework was implemented, integrating coding and testing was much easier to talk about.

Having management figure out their new roles first, and then getting a build process framework in place with everything in source code control, were key to the successful transition to agile. Another success factor was having representatives from all teams—Engineering, QA, the CM, network, and the system administrator groups and product teams—participate in daily stand-ups and planning activities. This way, when testing issues came up, they could be addressed by everyone who could help. As Christophe says, their approach integrates everyone and puts a focus on testing.

See the bibliography for a link to some of Christophe’s writings on managing agile teams.

Agile Project Teams

Agile project teams are generally considered cross-functional, because each team has members from many different backgrounds. The difference between a traditional cross-functional team and an agile team is the approach to the whole-team effort. Members are not just “representing” their functions in the team but are becoming true members of the team for as long as the project or permanent team exists (see Figure 4-1).