Agile Testing: A Practical Guide for Testers and Agile Teams

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).