Testing Extreme Programming (Paperback)

~ (Author), Tip House (Author)

Editorial Reviews

Product Description

Testing is a cornerstone within the burgeoning discipline of Extreme Programming. Much has been written about XP, but to date, no book has specifically addressed the key role that the tester plays in this lightweight methodology. This new book defines how an XP tester can optimally contribute to a project, including what testers should do, when they should do it, and how they should do it. Each teaching point is supported by practical examples, helpful suggestions, and proven techniques that will help readers improve the quality of their next project. The material is based on the authors' real-world experience making XP work within development organizations. The book also provides a unique "Road Hazard Survival Kit" with copious resources that help the tester address common pitfalls. Both testers unfamiliar with XP, and XP devotees unfamiliar with testing, will benefit greatly from this book.

From the Back Cover

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.

0321113551B09262002

See all Editorial Reviews

Product Details

• Paperback: 336 pages
• Publisher: Addison-Wesley Professional (November 4, 2002)
• Language: English
• ISBN-10: 0321113551
• ISBN-13: 978-0321113559
• Product Dimensions: 9.1 x 7.4 x 0.8 inches
• Shipping Weight: 1.1 pounds (View shipping rates and policies)
• Average Customer Review: 4.5 out of 5 stars  See all reviews (6 customer reviews)
• Amazon.com Sales Rank: #343,946 in Books (See Bestsellers in Books)

  Popular in this category: (What's this?)

  #95 in

  Books > Computers & Internet > Programming > Software Design, Testing & Engineering > Testing

Customer Reviews

Most Helpful Customer Reviews

19 of 22 people found the following review helpful:

4.0 out of 5 stars Resolution of an apparent contradiction about testing, May 6, 2003

By	Charles Ashbacher "([e-mail])" (Marion, Iowa United States([e-mail])) - See all my reviews (TOP 50 REVIEWER)

While I yield to no one in recognizing the value of testing software, my first reaction to reading the title of this book was one of skepticism. One of the fundamental principles of extreme programming (XP), is that the software is developed in small increments, each of which must pass a unit test before the next change is made. In fact, in many cases the unit test is written by the developers before they write the code. These incremental tests are also carried out by the two-person coding team, so it seemed strange to be reading about testing XP. From the title and blurbs on the covers, it was a natural assumption that the focus would be on testing other than that done by the development teams.
After reading the book, that skepticism has largely gone, although I do possess some residual doubts about XP and how it scales. The basic point is that programmers are very good at testing their code at the unit level, but weak when asked to verify it at the system level. I agree with the authors that there should be a dedicated tester who examines the code at a level higher than the unit. However, I am also of the opinion that this is a confirmation of the doubt about XP expressed by so many observers, namely that it does not scale up to large projects well. The testers that they are proposing are more in the realm of a manager responsible for testing rather than a tester.
This is of course very sensible. Once the programmers start producing code tested at the unit level and the integration process begins, someone must be responsible for the smooth flow and testing of the integration. This is also the level where the ever-present customer, another fundamental principle of XP, really sees the functionality of the code for the first time. While XP proponents speak a great deal about having the customer at the side of the coding team, realism dictates that they will generally be restricted from that level. Only the most technically sophisticated customer will be able to glean any useful information from most of the unit tests that will be performed. This is where the additional layer of the test manager is of use. By creating and demonstrating the higher level tests, the test manager can give the customer information that they will understand and can respond to.
The authors also put forward a very controversial statement, "No manual tests. All acceptance tests on an Extreme Programming project must be automated." While I am in general agreement with the principle that tests should be automated for easy repetition at each level, the reality is that nearly every use of words such as { "no", "never", "all"} is too extreme. Especially when you are describing something as subjective as the behavior of computer programs and the human response to them. How one can automate the response of a customer to the appearance of a GUI interface is something I do not yet understand, and this is mentioned, but not examined in the book.
One very positive aspect of the book is the exercises at the end of the chapters, and the authors do the very commendable thing and provide solutions at the end. After years of frustration with math and computer books that list exercises but avoid solutions, any book where they are included must be given a higher rating.
After reading this book, my confidence in the value of XP has increased, ironically because one of the fundamental weaknesses is examined with an explanation of how to overcome it. The uber-tester is a concession to the problems of scaling, and the inclusion of such individuals will definitely make the development process run smoother. If you are going to use XP and your project is of any size, then you should read this book.

Published in the online Journal of Object Technology, reprinted with permission.

8 of 10 people found the following review helpful:

5.0 out of 5 stars An excellent book--for programmers, managers and testers, November 1, 2002

By	Michael Cohn "agile developer" (Lafayette, CO USA) - See all my reviews (REAL NAME)

This book is fantastic. I'm only a tester to the extent that everyone doing XP is a tester but I found many valuable things in this book. There are excellent chapters about how to estimate and plan releases and iterations, including excellent tips on finding hidden assumptions in your stories. I like the book so much that I just bought a copy for a tester who works for me and told him to go home, read it, and not come back until he has so that we can discuss how to put some of the book's advice into practice. Everyone working on an agile project (not just XP and not just testers) will benefit from this book. It is one of the best-written and most useful in the entire series.

6 of 8 people found the following review helpful:

3.0 out of 5 stars Extreme programming from the tester's perspective, November 20, 2002

By	Maxim Masiutin (Chisinau, Republic of Moldova) - See all my reviews (REAL NAME)

Amazon Verified Purchase

This book is a professional tester's perspective of being involved into an XP project. The book will invigorate the testers who never worked in XP environment to start doing this practice. The book starts with an introductory overview on XP, which is self-contained and should be easily understood by any tester, unless he or she has prejudices against XP. This introduction is helpful for those who inherently would like to use XP. The skeptical readers should first take attention to Kent Beck's "Extreme Programming Explained".

For those who don't like to imagine of someone in the tester "role" on an XP project, the authors encourage to think of having a programmer with a "tester focus". The authors define the tester role to fill the communication gap between the user and the programmers.

For those who are already practicing XP, this book should be a good repetition of the core XP practices. If you like to refresh in memory the essential aspects of XP, read this book. The authors give their own vantage point on XP, which compliments the original Kent Beck's idea.

This book also contains the introduction to some automated test tools like JUnit (a testing framework for Java) or JWebArt (an HTTP-based web testing tool). However, the JUnit introduction given in this book won't help great deal to the C++ programmers, because the CppUnit, the C++ testing framework, have sufficient differences from JUnit. What the XP community who work with C++ really miss at the date of publication of this book is a good CppUnit manual.

The book also have essential focus on story estimation and iteration planning, from the tester's perspective. However, from the programmer's point of view, this book contain very few useful ideas. The programmers might want to refer to Ron Jeffries' "Extreme Programming Installed" for some useful testing strategies, tips and tricks.