Lisa Crispin, author of the 2002 book Testing eXtreme Programming, and Janet Gregory have collaborated together to create a magnificently pragmatic tome that is a true tour de force in its field: Agile Testing: A Practical Guide for Testers and Agile Teams. The book is exactly what its title says, and should quickly become “the bible” for all would-be agile testers.

Right from the start it is obvious that this book is not about theory, but is borne from profoundly deep insight and broad experience on real world projects. It doesn’t just cover testing types and techniques, or values and principles, but also real world challenges from organizational culture to team logistics; and from technological and geographical constraints to tooling, environments, and communication/collaboration.

Chapter 1 – What Is Agile Testing Anyway? is available online and it clearly sets the tone and style of the book. It begins with a very concise visual depiction of its content and structure (in a fashion that resembles a mindmap):

Every chapter of the book begins with a diagram like this, and I think it really works quite well. Similarly, each chapter ends with a bulleted list of highlights summarizing the “key take-aways” of the chapter. The subsections on “How is Agile Testing Different?” and “The Whole-Team Approach” are particularly useful, and very representative of the kinds of real-world insights that you’ll find in every chapter. Chapter two lists a set of ten principles for agile testers that are worth noting here:

• Provide continuous feedback - The agile tester is central to providing the team with feedback: Acceptance criteria is the most concrete way to measure positive progress on an agile project. Tests also help identify issues and capture decisions on appropriate future direction.
• Deliver value to the customer - The insistence on acceptance tests is a "reality check" on scope creep. Acceptance tests help us all understand what it means to realize a customer's needs.
• Enable face-to-face communication - Testers can often be the ones on a team responsible for bridging the communication gap between customers (BAs, product owners, etc.) and programmers. A tester can be the one who physically brings these people together, as well as the one who drives derivation of a common language between the two parties.
• Have courage - One of the larger challenges of agile is in sustaining a fast-paced iterative environment, where every two weeks we need to ship quality software. This challenge demands significant courage. Yet the irony is that we also need to understand that iterations afford us opportunities to learn how to fail and adapt--something that can require an even heavier dose of courage!
• Keep it simple - Agile testers can help push back against an insistence on overly-elaborate features. Testers can also help the customer understand how to incrementally deliver value. They must learn an appropriate balance of iterative testing-- just enough to provide the right confidence in delivering software.
• Practice continuous improvement - A key element of using iterations is to allow for learning to take place. Testers should be part of retrospectives (and if you're not consistently adapting based on the results of retrospectives, you're not agile enough.) Testers should also treat their career as a profession by continually learning more about testing practices, tools, and the system itself.
• Respond to change - Agile testing is dramatically different in that there are few true "cutoff points"--things keep changing and thus must be continually re-tested. This requires automation! The agile tester learns to cope with the customer changing his or her mind from iteration to iteration, and correspondingly learns how to incrementally flesh out necessary testing specifications.
• Self-organize - In a true agile team, everyone has the capability to act as a tester. Agile teams know how to shift focus as needed; from time to time, for example, it may be prudent for programmers to turn their attention toward helping verify a "done" but not "done done" feature.
• Focus on people - Testers are often at the bottom of the totem pole in a non-agile software development team. Work is thrown at them, their available slice of time is continually squished, and programmers often look upon them as lessers. In an agile team, every shares the responsibility for ensuring that we are building quality product. Agile testers are key in bringing their testing expertise to the team.
• Enjoy - The ability to help drive the process and be a true, equal contributor to a team can be extremely gratifying for an agile tester.

Part III encompasses seven chapters (6-12) and is what many would consider the “meat” of the book. It covers the Agile Testing Quadrants (or matrix) as initially defined by Brian Marick and delves deeply into tips and techniques for addressing each of the quadrants defined by the Business-Facing vs. Technology-Facing dimension and the Team-Supporting vs. Product-Critiquing dimension. Its shows in which quadrant each of the various types of testing “fit” and gives advice for doing them pragmatically. All of them are covered in-depth: unit-testing, component-testing, functional-testing, scenario-based testing, story-based testing, usability testing, acceptance-testing, performance & load-testing, ‘ility’-testing, alpha & beta-testing, exploratory-testing, security-testing, prototypes, simulation and examples.

Part IV (chapters 12-14) are devoted to test-automation challenges and implementation strategy and tactics, while Part V (chapters 15-20) walks us through an iteration in the life of an agile tester, comprising all activities and collaborations from iteration-start to iteration-end.

Part VI (chapter 21) is the summary and is available online at InfoQ.com. It nicely wraps everything up by describing and summarizing the key success factors for agile testers and agile testing:

1. Use the whole-team approach.
2. Adopt an agile testing mind-set.
3. Automate regression testing.
4. Provide and obtain feedback.
5. Build a foundation of core practices.
6. Collaborate with customers.
7. Look at the big picture.

About the Reviewer
Brad Appleton is an enterprise SCM/ALM solution architect for a Fortune 100 technology company. Currently he helps projects and teams adopt and apply agile development & SCM practices. Brad also author's the Agile CM Environments blog, and is co-author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, the "Agile SCM" column in CMCrossroads.com's CM Journal, and is a former section editor for The C++ Report. Since 1987, Brad has extensive experience using, developing, and supporting SCM environments for teams of all shapes and sizes. He holds an M.S. in Software Engineering and a B.S. in Computer Science and Mathematics.

Comments (0)

Write comment

Show/hide comment form