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