Agile Testing: A Practical Guide for Testers and Agile Teams

Everyone involved with delivering the product needs time and training to understand the concepts behind agile as well as the core practices. Experienced coaches can be used to give hands-on training in practices new to the team, such as test-driven development. In larger organizations, functional test managers can become practice leads and can provide support and resources so that testers learn how to communicate and collaborate with their new teams. Programmers and other team members need similar help from their functional managers. Strong leadership will help teams find ways to migrate away from “mini-waterfall” to true collaborative development, where coding and testing are integrated into one process.

See the bibliography for a link to more information about XP Radar charts.

XP has developed a radar chart to help teams determine their level of adaptation to key XP practices. They measure five different key practices: team, programming, planning, customer, and pairing, and they show the level of adaptation to practices by teams. Figure 3-2 shows two such charts. The chart on the left shows successful adaptation, while the chart on the right shows that there are some problem areas.

Figure 3-2 XP Radar charts

Past Experience/Attitude

Lots of people have been through changes that didn’t stick. Some development organizations have lived through a succession of the “methodology du jour.” They throw up their hands and wonder, “Why should we do it again?” People get stuck in their old, unsuccessful patterns. Even when they try something new, they might revert to bad old habits when under stress. The following are just a few examples of people resisting change due to past experience and their perception of “the way things are”:

A tester sat in his cube and wouldn’t talk with the programmers about problems he was having. He complained that programmers didn’t understand what he wanted.

A tester couldn’t shake his existing attitude that programmers didn’t know how to write good code, or how to test it. His condescending attitude was clear to all, and his credibility as a tester was challenged.

A customer threw up his hands when the programmers did something he didn’t like, because they “always” do what they want anyhow.

When faced with a transition to agile development, people like this often leave without giving the new process a chance. Agile development isn’t for everyone, but training and time to experiment can help adjust attitudes. Ask everyone to be part of the solution, and work together to find out what processes and practices work best for their particular situations. The self-organizing team can be a powerful tool to use to reassure all members of the development team that they’re in control of their own destiny.

Cultural Differences among Roles

Each new agile team member is making the transition from a different perspective. Programmers are often used to writing production code and getting it released as quickly as possible. System administrators and database experts might be accustomed to working in their own silo, performing requests on their own schedule. Customers may never have talked directly with development team members. Testers might be used to coming in at the end of the project and not interacting much at all with programmers.

It’s no wonder a transition to agile can be scary. Teams can come up with rules and guidelines to help them communicate and work well together. For example, Lisa joined a new agile team whose rule was that if someone asked you to pair with her, you had to agree. You might not be able to do it right that minute, but as soon as you could free yourself up, you had to go help your teammate.

Identify what people doing different activities need, and find ways to provide it. Customers need some way to know how development is progressing and whether their conditions of satisfaction are being met. Developers need to know business priorities and requirements. Testers need ways to capture examples and turn them into tests. All team members want to feel they are valued, first-class team members. Each team member also needs to feel safe and to feel free to raise issues and try new ideas. Understanding the viewpoint of each role helps teams through the transition.

Introducing Change

When implementing any change, be aware of the side effects. The first stage may be chaos; your team isn’t sure what the new processes are, some groups are loyal to old ways, and some people are unsure and disruptive. People mistake this chaotic stage for the new status quo. To avoid this, explain the change model up front and set expectations. Expect and accept perceived chaos as you implement agile processes. Find the areas of the most pain, and determine what practices will solve the problem so that you can get some immediate progress out of the chaos.

Talk about Fears