Review By: Cathy Bell
07/08/2010You can sit down and read many books that guide you through the processes necessary to produce a quality software product. But most of us work on projects that may be well intentioned in the beginning and are following any one of a myriad of software quality processes, but as the deadline gets ever closer, the processes are bent and often discarded in favor of releasing the product on time. How many of us are putting the finishing touches on requirements, test plans, and user manuals after the product’s release?

“The quality of a great product lies in the hands of the individuals designing, programming, testing, and documenting it, each of whom counts. Standards, specifications, committees, and change controls will not assure quality, nor do software houses rely on them to play that role. It is the commitment of the individuals to excellence, their mastery of the tools of their crafts, and their ability to work together that makes the product, not the rules”(vii).

I’m sure we are all collectively nodding our heads in agreement with that statement. This book is all about mastering our craft, not necessarily following the rules.

The authors give us a brief overview of the content of the book, noting the way the book is structured and pointing out how the reader may get the most benefit from the book—as a novice tester, experienced tester, manager, or even as a teacher of this material. Each chapter starts with an explanation of why it was included and what is covered in the chapter. This introductory text also lists other “interesting readings” and refers to other chapters within the book that may further clarify material in the following chapter.

The book is broken down into three sections: Fundamentals, Specific Testing Skills, and Managing Testing Projects and Skills. The basics are covered in chapters 1–5 starting with a simple example: the program takes two numbers as input from the user, displays those numbers on the screen, adds the numbers, and displays their sum. The book shows that there are 39,601 possible number combinations that could be tested, and this does not include entering alpha characters, special characters, or function keys. The novice tester may be overwhelmed by this statistic, but the book shows how to determine what tests to conduct while it explains the testing terms. This general format is followed throughout the book, presenting the reader with a testing problem then explaining the best solution for the problem while defining relevant terms.

But the greatest value in this book is the practical guidance that is the most honest testing insight I have read to date. The advice not only covers the testing processes but also gives insight into the politically correct way to handle issues with developers and management alike.

So are we verifying that the program works or that the program doesn’t work? “You will do your best work if you think of your task as proving the program is no good. You are well advised to adopt a thoroughly destructive attitude toward the program. You should want it to fail, you should expect it to fail, and you should concentrate on finding test cases that show its failures.” Have you ever read that admonishment in another testing book? “The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.”

Most programmers are not thinking of what will happen if the user performs functions outside the boundaries of the program’s parameters; that is our job as testers. This issue is one that is not covered in other testing publications because it deals with the human factors—our relationship as testers with the programmers whose code we test. While discussing bug reports and analysis in chapter 5, the authors admonish us, that our job is to tell programmers that what they did was wrong, something most people do not take well. But even if our opinion is that the programmer is “sloppy, stupid, or unprofessional,” we have to curb the urge to say so, out loud or in a written report, as we will diminish our own ability to have our reports taken seriously. This advice alone is worth the cost of the book, if you can get a new tester (or any tester) to see the value in this advice.

Chapter 7 covers test case design and asks the reader (not just students) to select a commercially available program and write test cases for five data-entry