The subtitle of this book announces that it presents a people-oriented approach to software testing, and that promise is certainly fulfilled. The book has little technical content; its focus is almost entirely on the managerial aspects of testing and the political problems faced by testers in large software organizations.
The book is organized around ten people-related “challenges” that face software testers, in order of increasing difficulty:
Getting trained in testing
Building relationships with developers
Testing without tools
Explaining testing to managers
Communicating with customers
Making time for testing
Testing what’s thrown over the wall
Hitting a moving target
Fighting a lose-lose situation
Having to say no
Each of these challenges is discussed in a separate chapter. The chapters all have more or less the same organization, with subsections labeled “Overview,” “State of the Practice,” “Impact on Testing,” “Solutions to the Challenge,” “Guidelines for Success,” “Solution Impediments,” and “Plan of Action.” Certain themes are emphasized throughout the book.
Although testers and developers often view each other as adversaries and are viewed that way by management, such views are mistaken. When everyone on a project understands that a defect discovered and resolved is one step closer to a quality product, everyone wins.
Management should give testers and the testing process the respect they deserve and should provide the testing group with adequate training and tools.
Testing should be a process that can be managed, measured, and repeated, with agreed-upon standards and responsibilities. Then people know what to test, when to test it, who should do the testing, and what the criteria for success are. Standardized test reports, delivered regularly, are particularly valuable.
Customer involvement in testing, often in the form of beta testing, can be useful in revealing whether a software product really meets its users’ needs.
Because testing is usually the last step in software development, it is performed under intense time pressure. Management must be realistic about what testing can accomplish and what kinds of defects can be removed.
The authors seem ambivalent about whether they are addressing the people who do the actual testing, or their managers. Normally, I would expect to find some description of the intended audience in the preface, but there is none. The problems caused by this ambivalence show up, for example, in chapter 2, which presents a self-assessment procedure for testers. There are ten questions. The first two have to do with the adequacy of formal training in the practice of software testing and in supporting areas such as risk analysis and communication skills--matters over which the testers presumably have some control. But most of the others deal with management issues, such as the adequacy of the amount of time senior management devotes to managing software testing--matters over which the testers are unlikely to have any control. The procedure would make more sense as a checklist specifically for managers (“do we provide the formal training to our testers?”), but that is not how it is presented.
The authors also make many assumptions about the organizational rubric under which testing is performed--for instance, that developers do not do all their own testing, and that the organization is fairly large. These assumptions should have been spelled out, so that readers would have some basis for judging how applicable the advice is likely to be. Also, although the authors include anecdotes about their testing experiences, there are no references at all to how specific, actual organizations go about testing, for better or for worse.
My overall reaction to this book is that, as a wag once put it, it is the sort of thing that people who like this sort of thing will like.