Review By: Lee Copeland
07/08/2010If you are new to Extreme Programming and/or new to testing, this book is the place to start. Weaving together the XP development process and the basics of testing, the authors provide a good introduction to this emerging discipline.

The book comprises three parts. Part 1 is a short introduction to the role of the XP tester including chapters on why XP teams need testers, how XP teams benefit from having testers, and how quality relates to the XP approach. Part 2 takes us on a “test drive” through an XP project. Here the authors describe in more detail the processes involved in defining and testing user stories; release planning; defining, estimating, and writing the acceptance tests; defining and estimating the development iterations; and the role of automated and manual testing (chapter 19 on Manual Tests is fantastic!). This part ends with a thorough discussion of automation for XP projects at both the unit and acceptance levels including tools to make testing more productive. Part 3 discusses some of the challenges we, as XP testers, may face in an imperfect world including problems with testability, selecting and implementing tools, introducing XP into your organization, and using XP on very large projects.

This book is extremely relevant to testers today as their organizations move to the Extreme Programming approach to software development. The authors’ writing style is clear, concise, and humorous. Personal stories and experience add significantly to our understanding.

On the other hand, I have some concerns: not with the book, but with the Extreme Programming process the authors describe and the role of testers within it.

In the movie “Treasure of the Sierra Madre” a bandit named Gold Hat responds to Humphrey Bogart’s challenge for identification saying something like, “Badges? Badges? We don’t need no stinkin’ badges!” As I read the original descriptions of Extreme Programming I saw the same approach. The XP team consists of customers and programmers, working closely together, but “Testers? Testers? We don’t need no stinkin’ testers!” Now, if the “fathers” of XP were right, and they are not needed, then the authors of this book are wrong. If, on the other hand, the authors are right, then the fathers were wrong. And if they were wrong about the need for testers, what else were they wrong about, and, will we discover those problems too late in our projects?

Let me quote from the book: “This type of thing [missing and misunderstood requirements] happens a lot in software development projects. As developers, we tend to focus on items that are important or interesting to the development process. How often have you been involved in projects that got the really hard part right but missed the easy stuff—which, unfortunately, turned out to be the very thing that mattered most to the customer? This is where a tester can make the biggest contribution to a software project: by thinking about the system from the viewpoint of those who have to live with the solution …” (page 13). As I understand XP, the {customer, programmer} team is responsible for getting it right, but according to the authors, they can’t. The authors of this book must then patch the XP process with testers.

On the next page: “If the customer wants … [a particular requirement], the tester makes sure this was included in the programmers’ estimates.” Again, an admission that the XP team {customer, programmer} can fail in their responsibilities.

One last admission (although the book has many of them): “XP calls for programmers and the customers to do these things. But in practice, these goals can be overlooked in the rush to produce. A tester who’s focused on them helps the rest of the team meet them” (page 44).

The author’s solution is to “patch” the XP process by adding testers. Is this the proper approach or was XP simply fatally flawed from inception?