Book Review: Perfect Software and Other Illusions About Testing

“Perfect Software and Other Illusions About Testing”, by Gerald Weinberg, is the best book on testing I have ever read.  It is a must-read for anyone who works with software: CEOs, CTOs, scrum masters, team leads, developers, product owners, business analysts, and software testers.

Before I get into why this book is so great, I’ll first acquaint you with the author.  Gerald “Jerry” Weinberg (1933-2018) was involved in the creation of software for over fifty years.  Early in his career he worked for NASA on Project Mercury, the project that created spacecraft that allowed a human to orbit the earth.  For decades he consulted with companies about building quality software, and over those years he gained a great deal of wisdom about software testing.  “Perfect Software”, which was published in 2014, seems to me to be the culmination of his years of experience.

The book is divided into several chapters, each of which looks at a particular aspect of software testing. Many examples are given from Jerry’s consulting experience, and each chapter closes with a summary and a list of common mistakes that companies make.  Rather than summarizing the lessons he imparts, I think it would be best to include Jerry’s own words here.  Here are some of my favorite quotes from the book:

“Before you even begin to test, ask yourself: What questions do I have about this product’s risks?  Will testing help answer these questions?”

“There are an infinite number of possible tests…Since we can’t test everything, any set of real tests is some kind of sample- a portion, piece, or segment that is in some way representative of a whole set of possible tests.”

“Knowing about the structure of the software you’re testing can help you to identify special cases, subtle features, and important ranges to try- all of which can help narrow the inference gap between what the software can do and what it will do during actual use.”

“Testing gathers information about a product; it does not fix things it finds that are wrong.”

“If you’re going to ignore information or go ahead with predetermined plans despite what the tests turn up, don’t bother testing.”

“If you blame messengers for bringing news you don’t want to hear, you’ll be rewarded by not hearing the news you should hear.”

“Quality is a product of the entire development process.  Poor testing can lead to poor quality, but good testing won’t lead to good quality unless all other parts of the process are in place and performed properly.”

“Testing starts at project conception, or before. If you don’t know this, you don’t understand testing at all.”

“Without a process that includes regular technical reviews, no project will rise above mediocrity, no matter how good its machine-testing process.”

“No developer is good enough to consistently do it alone, and do it right.”

“Data are meaningless until someone determines their meaning.  Different people give different meanings to the same data.  Gather data, then sit down and ponder at least three possible meanings.”

“When someone says, ‘The response should be very fast’, what does that mean, exactly?  What meanings do ‘should’, ‘very’, and ‘fast’ give to the stated information?”

“Numbers can be useful, but only if they’re validated by personal observation and set in context by a story about them.”

“Garbage arranged in a spreadsheet is still garbage.”

Jerry uses many great hypothetical scenarios to illustrate his points, and he also uses real-world examples from his years of consulting.  Here are some of my favorites:

• The tester who didn’t log a bug he found because it wasn’t in “his” component
• The manager who thought that the project was ready to ship because they ran 600,000 test cases and “nothing crashed the system”
• The team who thought their biggest problem was their bug-tracking system, because the system couldn’t handle their 140,000 open bugs
• The team who took so long to triage bugs that couldn’t make a decision on any of them, resulting in 129 undiscussed and unfixed bugs
• The tester who assumed that her new automated test tool was working correctly because all the tests displayed in green at the end
• The developer-tester team who were gaming the bug bounty system by having the developer add bugs to the code, the tester find the bugs quickly, and the developer fix them just as quickly, resulting in rewards for both
• The VP of Development who wanted a really big written test plan so he could have something big to slam down on a desk to “prove” that they had tested well

If you would like to think about what role testing plays in your software development project, what constitutes a good test, how to plan testing for a project, or how to interpret test data in order to make management decisions, then “Perfect Software” is the book for you.  I plan to re-read this book every year to make sure that I have fully retained all the lessons it offers.