Categories >> Testing

Reviews

Applicable mostly to 1997, but not 2009.

Note to self: check the publish date before buying any more books on software testing.

Generally, this book discusses issues and state-of-the-art capabilities that were typical in 1997. Very little of it is still applicable today, and the suggestions provided to solve issues are not earth-shattering. "Quantify the cost" and "get management buy-in" are essential steps not just for improving software testing in your organization, but of any type of improvement you want to make.

The authors' "State Of The Practice" section in each chapter is a fictional short story contrived to illustrate the worst possible situation for a test engineer. For that small group of companies still living in the dark ages of software engineering, these issues might occur in 2009. But, most organizations are at varying levels of greater emphasis and sophistication regarding testing at all phases of software development. Certainly more improvements can be made in our industry, but things aren't nearly as bad as the authors illustrate.

Finally, the authors are associated with ASQ, and their perspectives on software testing are thus limited. ASQ focuses on quality on a variety of fronts with respect to software engineering. Testing is one critical component of that, but the ASQ emphasis on testing is not as deep as that of ISTQB, for example.

I'd (marginally) recommend this book in 2009 and beyond if you're absolutely new to the world of software testing, and/or are working for a company that is, in fact, years behind the curve on this topic. Otherwise I'd recommend reading the various software testing magazines, attending StarEAST or StarWEST conferences, or otherwise using ISTQB as a resource for pure testing information.

Software testing as if people mattered

Much has changed in software development and testing practices since this text was written in the late 90's. However, many of the identified challenges are still with us. I find myself rereading this book as it is a useful reference for a test manager. The authors identify dual disparate roles for the software tester. In role one, the focus is on the task of testing software, such as test planning, test design, and execution. In role two, the tester or test manager's role is more as a politician and marketer to protect the test staff and promote the value they bring to each project . The text focuses on the second role, which elaborates on what the authors identify as the top ten people oriented challenges for the software test professional.

The first section of the book includes an assessment to help you identify your strengths and weaknesses in meeting people related testing challenges. The bulk of the text contains individual chapters on the top 10 challenges. The challenges are explained along with guidelines to overcome the challenge. Chapters can be read out of order and this format allows you to focus on your weaknesses as identified in the self assessment. The last section of the book describes a six step change process to implement improvements. My favorite two chapters were "Explaining Testing to Managers" and "Getting Trained in Testing." Highly recommended.

Still valid, still useful

When this book was written software testing was starting to consolidate into an 'honorable' profession, and the number of good books about testing could be counted on your fingers (and probably a few toes). The discipline has matured into a profession, and there are so many excellent books on the subject now that it boggles my mind.

You'd think that the top ten challenges listed in this book would have been long ago resolved and replaced with a new set. Sadly, that isn't the case. Each challenge listed is as valid today as it was when this book was written, and except for #10 on the list (getting trained in testing), which has dramatically improved, the other nine are still there. Read the book. Take the advice of the two authors, both of whom are seasoned professionals who give the solutions to these challenges, and move the profession forward.

Here are the top five challenges that I see today, drawn from the list in the book:

#1 today, #6 in the book: Communicating with Customers -- And Users
#2 today, #3 in the book: Hitting a Moving Target
#3 today, #1 in the book: Having to Say No
#4 today, #4 in the book: Testing What's Thrown Over the Wall
#5 today, #2 in the book: Fighting a Lose-Lose Situation

Your order may be different, but I am willing to bet that the list will be the same. This book does give realistic solutions to these problems, so if you agree with the list, then you'll find this book valuable.

Excellent review of the daily pitfalls of software testing

This is an excellent review of the biggest recurring problems of the software testing world. As I read the descriptions of each of the 10 challenges, I was astonished at how many of the pitfalls I fall into on a regular basis. Perry & Rice don't just lay out what the challenges are - they also discuss how to meet each one. Each item on the list has its own chapter with sections on the impact on testing, solutions to the challenge, impediments to implementing the solutions, and helpful guidelines to creating a plan of action. This is without a doubt an excellent book for those of us in the trenches of software testing each day. (One bit of advice, though - if you're looking for a book on "how to do software testing", look elsewhere. Perry and Rice have other good books on the subject, but this one is really intended to help you step back from your daily testing work and see where you could improve on your approach to it.)

Bringing testing out of the closet

Testing has often been the misbegotten portion of the software development process. Frequently neglected until the semi-chaotic end of the production cycle, the testing phase has traditionally been shortened to accommodate a fixed release date. The relationships between the developer and test groups are to some extent adversarial, but in so many cases it often breaks down into open hostility. Among developers, it is often considered demeaning to have to soil ones hands by actually testing the code. With such a sullied background, it is no wonder that production code is generally riddled with bugs.
As the authors of this book point out, all of the above are dangerous conditions. With the expansion of code reuse and RAD tools, the development of the initial iteration is going to be done at a faster pace than before. Since the number of pathways through the code is operationally infinite, the only way relatively bug-free code will be developed is by allocating more resources to testing and making the choice and tracking of test cases a more scientific endeavor. The most significant point of the ten made in this book is that the testing process should be considered on an equal basis with that of development so that both groups communicate as equals. Without that, all the fancy, efficient tools in the world are reduced to the level of mere toys.
This is a book that can and should be read by developers, managers and yes, even testers, as all will benefit from the simple words of wisdom.