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

We build telecommunications software for mobiles, so we usually install our software at night, when no one is likely to make calls. This might be during our office hours, when we’re handling a customer in Australia, but usually it is during our nighttime.

My colleagues who do the actual installation—there are three within our team—are most likely to appear late during next day’s office hours because we don’t have a separate group for these tasks.

As businesses and development teams become more global, release timing gets more complicated. Fortunately, production configurations can make releases easier. If your production environment has multiple application servers, you may be able to bring them down one at a time for release without disrupting users.

New releases should be as transparent as possible to the customer. The fewer emergency releases or patches required after a release, the more confidence your customer will have in both the product and the development team.

Learn from each release and take actions to make the next one go more smoothly. Get all roles, such as system and database administrators, involved in the planning. Evaluate each release and think of ways to improve the next one.

Summary

This chapter covered the following points:

Successful delivery of a product includes more than just the application you are building. Plan the non-software deliverables such as documentation, legal notices, and training.

The end game is an opportunity to put the spit and polish, the final finishing touches, on your product.

Other groups may be responsible for environments, tools, and other components of the end game and release. Coordinate with them ahead of time.

Be sure to test database update scripts, data conversions, and other parts of the installation.

UAT is an opportunity for customers to test against their data and to build their confidence in the product.

Budget time for extra cycles as needed, such as post-development cycles to coordinate testing with outside parties.

Establish release acceptance criteria during release planning so that you can know when you’re ready to release.

Testers often are involved in managing releases and testing the packaging.

When releasing the product, consider the whole package—what the customer needs and expects.

Learn from each release, and adapt to improve your processes.

Part VI Summary

In Chapter 21, “Key Success Factors,” we pull things together and summarize the agile approach to testing.

Chapter 21 Key Success Factors

Having traveled through an iteration and beyond, following an agile tester as she engages in many activities, we can now pick out some key factors that help testers succeed on agile teams and help agile teams succeed at delivering a high-quality product. We think agile testers have something special to offer. “Agile-infected” testers learn how to apply agile practices and principles to help their whole team produce a better product. “Test-infected” programmers on agile teams learn how to use testing to produce better work. Lines between roles are blurred, but that’s a good thing. Everyone is focused on quality.

We have gleaned some critical testing guidelines for agile teams and testers from our own trial and error as well as from teams with which we’ve worked. These guidelines are built on the agile testing matrix, on our experience of learning to overcome cultural and organizational obstacles, our adventures in performing the tester role on agile teams, and our experience of figuring out how best to use test automation. We like lucky numbers, so in this chapter we present seven key factors that help an agile tester succeed.

We asked a small group of people who were reviewing some of our chapters to suggest the order in which to present these success factors. The results varied quite a bit, although many (but not all) agreed on the top two. Pick the success factor that will give you the biggest return on investment, and start working on it today.

Success Factor 1: Use the Whole-Team Approach

When the whole development team takes responsibility for testing and quality, you have a large variety of skill sets and experience levels taking on whatever testing issues might arrive. Test automation isn’t a big problem to a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team designs testable code.

Making testers truly part of the development team means giving them the support and training they need to adapt to the fast pace of agile development. They have time to acquire new skills in order to collaborate closely with members of both the development and customer teams.

If you manage an agile team, use the suggestions in Part II, “Organizational Challenges,” to help your team adopt the whole-team approach. Remember that quality, not speed, is the goal of agile development. Your team needs testers to help customers clarify requirements, turn those into tests that guide development, and provide a unique viewpoint that will promote delivery of a solid product. Make sure the testers can transfer their skills and expertise to the rest of the team. Make sure they aren’t pigeonholed in a role such as only doing manual testing. Make sure that when they ask for help (which may require considerable courage on their part), their team members give it. The reverse is true, too; a tester should step up whenever someone needs assistance that they can provide.

If you’re a tester on an agile team, and there are planning meetings and design discussions happening that don’t include you, or the business users are struggling to define their stories and requirements alone, it’s time to get up and go talk to the rest of the team. Sit with the programmers, invite yourself to meetings, and propose trying the “Power of Three” by involving a tester, a programmer, and a business expert. Be useful, giving feedback and helping the customers provide examples. Make your problems the team’s problems, and make their problems yours. Ask your teammates to adopt a whole-team approach.

See Chapter 2, “Ten Principles for Agile Testers,” for an example of how the “Power of Three” works.

Success Factor 2: Adopt an Agile Testing Mind-Set

In Chapter 2, “Ten Principles for Agile Testers,” we cautioned agile testers to lose any “Quality Police” mind-set they might have brought with them. You’re on an agile team now, where programmers test and testers do whatever they can think of to help the team deliver the best possible product. As we emphasized in Chapter 2, an agile testing attitude is proactive, creative, open to new ideas, and willing to take on any task. The agile tester constantly hones her craft, is always ready to collaborate, trusts her instincts, and is passionate about helping the team and the business succeed.