We’ve tried to provide these layers of detail in this book. We’ll approach agile testing from a few different perspectives: transitioning into agile development, using an agile testing matrix to guide testing efforts, and explaining all the different testing activities that take place throughout the agile development cycle.
How to Use This Book
If you aren’t sure where to start in this book, or you just want a quick overview, we suggest you read the last chapter, Chapter 21, “Key Success Factors,” and follow wherever it leads you.
Part I: Introduction
If you want quick answers to questions such as “Is agile testing different than testing on waterfall projects?” or “What’s the difference between a tester on a traditional team and an agile tester?,” start with Part I, which includes the following chapters:
These chapters are the “tip of the iceberg” that Robin requested in his user story. They include an overview of how agile differs from a traditional phased approach and explore the “whole team” approach to quality and testing.
In this part of the book we define the “agile testing mind-set” and what makes testers successful on agile teams. We explain how testers apply agile values and principles to contribute their particular expertise.
Part II: Organizational Challenges
If you’re a tester or manager on a traditional QA team, or you’re coaching a team that’s moving to agile, Part II will help you with the organizational challenges faced by teams in transition. The “whole team” attitude represents a lot of cultural changes to team members, but it helps overcome the fear testers have when they wonder how much control they’ll have or whether they’ll be expected to write code.
Some of the questions answered in Part II are:
Part II also introduces some topics we don’t always enjoy talking about. We explore ideas about how to transition processes and models, such as audits or SOX compliance, that are common in traditional environments.
Metrics and how they’re applied can be a controversial issue, but there are positive ways to use them to benefit the team. Defect tracking easily becomes a point of contention for teams, with questions such as “Do we use a defect-tracking system?” or “When do we log bugs?”
Two common questions about agile testing from people with traditional test team experience are “What about test plans?” and “Is it true there’s no documentation on agile projects?” Part II clears up these mysteries.
The chapters in Part II are as follows:
Part III: The Agile Testing Quadrants
Do you want more details on what types of testing are done on agile projects? Are you wondering who does what testing? How do you know whether you’ve done all the testing that’s needed? How do you decide what practices, techniques, and tools fit your particular situation? If these are your concerns, check out Part III.
We use Brian Marick’s Agile Testing Quadrants to explain the purpose of testing. The quadrants help you define all the different areas your testing should address, from unit level tests to reliability and other “ilities,” and everything in between. This is where we get down into the nitty-gritty of how to deliver a high-quality product. We explain techniques that can help you to communicate well with your customers and better understand their requirements. This part of the book shows how tests drive development at multiple levels. It also provides tools for your toolkit that can help you to effectively define, design, and execute tests that support the team and critique the product. The chapters include the following:
Part IV: Automation
Test automation is a central focus of successful agile teams, and it’s a scary topic for lots of people (we know, because it’s had us running scared before!). How do you squeeze test automation into short iterations and still get all the stories completed?