Beyond Functional Testing
Agile development has always centered around testing and quality. That characteristic drew us to agile: Test first, test all the time, build in quality. However, since most teams were peopled with programmers, the emphasis was generally on functional tests that guide development. Testing practitioners, naturally, disapproved; they knew that software quality encompasses much more than simply checking that software meets initial requirements. Experts in areas such as exploratory testing, performance testing, usability, and user-experience testing challenged agile teams to realize that they had much more work to do.
At the same time, many testing practitioners could see advantages in delivering frequent business value; as well as using good development practices such as test-driven development, pairing, and refactoring to build in quality and work at a sustainable pace. Many joined agile teams or encouraged their own teams to embrace agile values. Their collaboration made customers and programmers aware that many different types of testing add business value. Agile teams grew their skills on the right side of the agile testing quadrants, including quality attributes such as security or load and performance needs.
Other disciplines are eager to contribute their own expertise on agile teams. One of the biggest challenges we’ve encountered over the years is helping business stakeholders articulate exactly what they want. Testers could elicit examples and turn them into tests, but often something was missing from the conversation. Jeff Patton’s story mapping provided one way to help teams slice features into stories and prioritize them. Later techniques such as impact mapping contributed good ways to identify which features to code next. Still, it can be hard to define exactly what the business and its customers want. Enter business analysis (BA) experts such as Ellen Gottesdiener and Mary Gorman, with their techniques to facilitate conversations with stakeholders. Agile testers can learn much from agile BAs; for example, making sure that we don’t waste time building the wrong things.
Designers also tend to be passionate about quality, and they have started getting more involved in the testing side. For example, the designers on Lisa’s current team are heavily involved in testing, often pairing with testers as they experiment with the initial design, and again once the story is delivered to make sure that the design was implemented properly.
Similarly, our programmer, system administrator, operations, and database expert teammates bring much to the party when it comes to building in quality and delivering business value frequently. These people are often as test-obsessed as the testers. We can collaborate with them to create infrastructure that gives our team fast feedback. Our teams have learned that we even need to test the resulting infrastructure, in order to move toward a goal of being able to deliver new software every day—or even multiple times per day. These practitioners from other disciplines help our teams find ways to speed up feedback from automated builds and tests, and provide reliable test environments. As these efforts gain in complexity, we may extend our testing to areas such as the continuous integration systems, build tools, and other infrastructure needed to execute tests.
It’s All About Value
Yes, doing a good job of testing is essential to agile development. Perhaps even more important, though, is identifying the most valuable feature to deliver next, using some of the techniques we’ve mentioned here. Testers can help to create a shared understanding of the problems that a business is trying to solve. Testers can also provide information about risk and uncertainty. Models such as Cynefin help us decide where to focus our testing efforts most productively.