Agile Testing: A Practical Guide for Testers and Agile Teams

When you start iterative development, use retrospectives to provide people with a place to talk about their fears and a place in which they can give feedback. Let people know that it’s normal to be fearful. Be open; teach them it is acceptable to say they are fearful or uncomfortable. Discuss each source of fear, learn from the discussion, make decisions, and move on. Fear is a common response to change. Forcing people to do something they don’t want is detrimental to positive change. Lead by example.

Lisa’s Story

Janet and I each joined our first XP teams at a time when many XP practitioners didn’t see any place for testers on an XP team. XP had a “Customer Bill of Rights” and a “Programmer Bill of Rights,” but the “Tester Bill of Rights” was conspicuously absent. Tip House and I came up with our own “Tester Bill of Rights” in order to give testers the support and courage to succeed on agile teams. Over the years, many testers have told us how much this helped them and their teams learn how testers work together with other team members. I don’t like too many rules, but they can be a good thing when they help the team to overcome cultural barriers and to understand how to work in new ways. The following list presents a “Tester Bill of Rights.” We encourage you to use it to help testers integrate into agile teams.

• You have the right to bring up issues related to testing, quality, and process at any time.

• You have the right to ask questions of customers, programmers, and other team members and receive timely answers.

• You have the right to ask for and receive help from anyone on the project teams, including programmers, managers, and customers.

• You have the right to estimate testing tasks and have these included in story estimates.

• You have the right to the tools you need to perform testing tasks in a timely manner.

• You have the right to expect your entire team, not just yourself, to be responsible for quality and testing.

—Lisa

Give Team Ownership

A critical success factor is whether the team takes ownership and has the ability to customize its approach. People can change their attitudes and their perceptions if they are given the right help. Lisa was able to observe Mike Cohn work with her team as a coach. As a self-organizing team, the team had to identify and solve its own problems. Mike made sure they had the time and resources to experiment and improve. He made sure that the business understood that quality was more important than quantity or speed. Every team, even a self-organizing team, needs a leader who can effectively interact with the organization’s management team.

Celebrate Success

Implementing change takes time and can be frustrating, so be sure to celebrate all successes your team achieves. Pat yourselves on the back when you meet your goal to write high-level test cases for all stories by the fourth day of the iteration. Get the team together for a trivia game or lunch when you’ve just delivered an iteration’s worth of work. Acknowledgment is important if you want a change to stick.

Chapter 18, “Coding and Testing,” covers how testers and programmers work together throughout the development process.

Integrating testers into development teams while letting them continue to report to a supportive QA manager is one way to ease the transition to agile development. Testers can find ways to move from an adversarial relationship with programmers to a collaborative one. They can show how they can help the team understand the customers’ needs and deliver appropriate business value. They can host enjoyable activities to build good team interactions. Having cookies or chocolate available for teammates is a good way to get them to walk over to your desk! Patience and a sense of fun are big advantages.

Overcoming Resistance to Agile

Mark Benander, a Quality Assurance Team Lead with Quickoffice, was on his fourth project on an agile team. The first was a major rewrite of their entire application, with a team of eight developers, one tester, and no test automation tool. He told us about his experiences in overcoming his concerns about agile development, especially about reporting to a development manager.

We were in a matrix management type of system, where a tester reports to a development manager, but the test manager is still officially the supervisor. This comforted me somewhat, but the majority of the issues I expected to occur, such as being overruled whenever I found an issue, never did. My concern wasn’t that I’d really end up thinking like a developer and just releasing anything, but that my manager, who was not a tester, wouldn’t care as much, and might not back up my concerns with the application.