Search in Book Reviews

The book covers some familiar ground and gives the usual definitions but if you have not done much formal (I mean organised not Formal Methods) testing before these are needed. Actually they are needed anyway in a skill where everyone seems to have their own definitions. The book is testing in general and will suite most commercial software: That is not the safety critical (usually embedded) systems.

The reason I suggest this is that the book has its feet firmly on the ground when it comes to how much work you can realistically do in general commercial development. One of the premises in the book is Most Important Tests method. What you need to test first and what can be left to later. This tends to suggest it is testing for desktop systems rather than embedded systems.

The other main theme is planning: Equipment, people, effort, cost and time. The book requires a Test Inventory and gives suggested templates for this method. Another method described is automating as much of the system infrastructure. That is the reporting and documentation not the actual testing. This uses MS Office, which most people have on their PC. The methods suggested here make this book worth the money on it's own.

There are some exercises and I became suspicious that this was going to be another "Course Book" but no, some of the answers are in the back of the book and the rest, along with other resources such as the templates used in the book are on

www.testersparadice.com

The exercises and suggestions at the end of some chapters are reasonably generic and they data analysis is reminiscent of Macabes Metrics. Though the only two coverage methods shown are statement and branch.

One fascinating area for me is the questionnaire at the back along with the results the author has at the time of going to press. These questionnaires the author has used on course on testing both sides of the Atlantic. The results are interesting, more so those that are split between the US and UK.

The book is written from many years experience and is honest. The author explains that at one time they were on "the other side of the fence" for some arguments and what changed her mind. She also understands why people have other views. This is refreshing in a book where an author usually evangelises their method against all others.

Personally I think this book is worth the money for all team and project leaders just for page 28... come to that just for the last paragraph on that page. Those 9 lines will be one of the most persuasive arguments for getting "creative", "free thinking, "programming is an art" programmers in line with procedures, standards and testing.

Overall I like this book. More for the web, database and desktop programmers than the embedded and high integrity areas but on balance a good book. Recommended.