Review By: Cathy Bell
09/17/2003

Imagine yourself sitting in the gallery at a trial in the Supreme Court of Quality. Three men are brought forth to testify and each is sworn in to “tell the truth, the whole truth, and nothing but the truth.” The busy court recorder captures all the testimony, and the transcripts are released to the public in book form. This is how the book could have come about, because the authors have definitely told the truth, and nothing but the truth.

The authors think like testers. Testers are usually from many diverse backgrounds, but as they remind us in chapter 2, “Most people agree: testers think differently.” Think of it this way: generally when testers speak, you will notice others (nontesters) getting a puzzled look on their faces, and their heads tilt to one side or the other. It’s a puzzled, bewildered, where-is-this-coming-from look. While reading this book, you too may find your head tilting to one side or the other, but most often you will find yourself nodding in agreement. This is a truthful, no-nonsense collection of lessons learned in software testing that is “to stimulate thought, not only agreement.” Instead of just giving charts, graphs, and sample test plans, the authors have given us a personal as well as professional look at their experiences. They also give us charts, graphs, and sample test plans they have implemented over the years.

The book is based on a context driven approach to software testing. The authors advise us to read a lesson or two and then ponder how that lesson fits into our own context, our particular work. Aha! One-size testing does not fit all. (They may be stoned in the coliseum for such outrageous opinions!) Chapter 1 explores the role of a tester, and they even dare to mention that you will not find all bugs! Chapter 2 reveals there is such a thing as thinking like a tester. Lesson 32 points out “if you expect to receive requirements on a sheaf of parchment, stamped with the seal of universal truth, find another line of work.” But what follows is useful guidance on how we can gather enough information, from many sources, that we can use in place of or in addition to requirements.

Chapter 3 covers testing techniques and presents the five-fold testing system. There is guidance on how to create a test matrix. Chapter 4, bug advocacy, starts by telling us “a tester who can’t report bugs well is like a refrigerator light that is only on when the door is closed.” They admonish us to give thought to what we write and how we write, and remind us that our reputation is often based upon our bug analysis and reporting efforts.

Chapter 5 touches on the sacred cow of automated testing. They again recommend selection of both the automated tools and the tests you will automate based on your context, and not to be fast-talked by tool vendor salesmen. The day a test tool can run all my tests, require minimal set up, and keep my desk clean is the day I worry about test tools replacing testers. Some of the truths covered in this chapter include the following: a test tool is not a strategy; test automation is a development process; test automation is a significant investment; and test automation projects require skills in programming, testing, and project management. Chapter 6 covers documenting testing (or, how many trees will the testers kill on this project?). Remember, standard templates are only good in the context of your testing effort.

Chapter 7, interacting with programmers, is a must-read for anyone considering a career in testing. Programmers are experts at how machines think, but they are not machines. They have feelings and care about the work they do. Who knew? Chapter 8 deals with managing the testing project. Remember, testing is only a subproject of the development effort, and we have to negotiate with the developers the best course for testing. Other lessons in this chapter deal with how we do our job managing testing: don’t try to create a control culture; be prepared for the build; there is no universal formula for knowing how much testing is enough; try testing in pairs; and a suggested structure for a weekly status report. Chapter 9, managing a testing group, is a must-read for all test managers. If you’re not a test manager, copy this chapter and leave it for them to read. I would highlight lesson 226, the morale of your staff is an important asset.

So, what are my options if I choose a career in testing? Chapter 10 has some practical guidance that might surprise you: whatever path you take, pursue it actively; extend your career beyond software testing; and lots of other companies are as screwed up as yours. Chapter 11 is the final chapter, showing us how to plan a good test strategy—again, within the context of your work. The appendix is a short explanation of the context driven approach to software testing, just in case you are not sure what it’s all about.

The most valuable lesson to me was: build a portfolio. There no such a thing as a sure thing, and your wonderful fulfilling job could be gone tomorrow. Your resume cannot show all of the skill you possess, whereas your portfolio certainly could. If you are prepared with a portfolio of your past experiences, it will be much easier to convince new employers that you really are as good as you say you are.

Your experience will certainly vary from the authors’; however, you will probably find a lot in common as well. There are many lessons to be learned from this book, and you’ll find yourself nodding in agreement more often than not.

Throughout the book references are given to other resources for further information. The wealth of references reinforces the authors’ efforts to provide the most useful and practical information available to make your life easier and more rewarding as a tester.