Testing Extreme Programming
The rapid rise in popularity of Extreme Programming (XP) has put the practice of software testing squarely in the spotlight of application development. At one time, testing was a neglected practice, a highly specialized activity that came as an afterthought as complex, code-intensive projects were rushed to completion. But in today's world of escalating quality expectations, testing is a key component of the development process.
XP accelerates testing by demanding its complete integration with development. This in turn has pushed software professionals to rethink their traditional attitudes toward testing. XP asks the entire development team to embrace testing. In fact, testing is so critical to the XP methodology that programmers are required to write automated tests before they begin coding. Until now, however, there has been a distinct lack of instruction specific to testing and how it relates to XP.
Testing Extreme Programming is a practical tutorial that gives software builders a lucid understanding of this important aspect of development. This book demonstrates how testing is central to the XP project, clearly spelling out what testing should be done and when and how it should be performed. The authors teach by example, and readers will be able to improve their knowledge of the testing process by completing the book's exercises.
In addition, this book:
- Provides a general overview of the XP methodology
- Defines the roles of XP team members
- Shows how to write effective tests before coding begins
- Helps you avoid the traps and pitfalls that can derail software projects
- Sheds light on the important practice of refactoring and how it relates to testing
- Compares and contrasts manual and automated tests
Many software engineers have dismissed XP as a throw-out-the-rulebook, anything-goes technique. It isn't. As this book shows, XP is a deliberate and disciplined approach to software development. Many software engineers have reaped the benefits of this agile methodology because its emphasis on testing eliminates much of the risk inherent in software projects. XP helps developers produce software on time, under budget, and at a higher quality level. But you can't XP if you don't test. With this book as a guide, you will learn to embrace testing. A sound testing program is the engine that drives an XP project.
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?