Perfect Software by Gerald M. Weinberg (2021)

The Book in Three Sentences

There is no perfect software. Testing provides information. Most people you work with will know little about testing.

Introduction

When I first read Perfect Software I didn’t understand it. It took a decade of experience for the lessons to sink in.

Please keep in mind that he published the book when he was 75 years old. You can tell the author has many decades of experience. The book is full of real life examples. I could recognize myself in characters from the examples, for more examples that I would like to admit. 😅

Some parts of this book are pure gold. When reading those parts, I was almost writing down everything stated in the book. Some parts of the book are common sense, but it’s still good to have it written down as a reminder and reference. Some parts of the book are more psychology than testing. Surprisingly, those parts are maybe the most important ones.

I really like the format of each chapter. First the main part, followed by a very short summary, then a lot of examples in the “common mistakes” section.

I really liked the chapters where the material is presented in the format of a story (9, 10, 12 and 13). I wish there was more of it. Even the entire novel that would teach you a topic (in this case software testing) by following different characters as the story develops. In the book, three fictional characters (a manager, a developer and a tester) are discussing a problem. First in the office, then over lunch. It’s written very well. I’ve heard that The Phoenix Project is written that way. (I haven’t read it yet, it’s on my to-read list.)

I also really liked the last two chapters (17 and 18). They are about scams. I’ve seen so many of them in my career. I’ve written more about it in the chapter summary.

I’ll try to summarize each chapter. For some chapters, I’ve included a quote that I particularly liked. Often the quote is the perfect summary of the chapter.

Reviewers

I would like to thank Tyler Cipriani for reviewing the article and a lot of advice on how to make it better.

Chapters

1 Why do we bother testing?

We are testing all the time. If we were perfect, we would not need to test. Testing provides information. Testers should not decide if the project is ready, that’s the manager’s job.

We can predict anything except the future. (Page 8.)

2 What testing cannot do?

Don’t test if you don’t plan to use the information gathered.

3 Why not just test everything?

There are an infinite number of tests. You can’t think and run them all. Make the best use of your resources and time by running the best sample you can.

Testing can be exhausting, but it can never be exhaustive. (Page 24.)

4 What’s the difference between testing and debugging?

Many different tasks requiring many different skills are often lumped under the rubric of testing. (Page 36.)

5 Meta-Testing

You can greatly improve the efficacy of your testing, and lower your costs, if you learn to use meta-information - information about the quality of information. (Page 47.)

6 Information immunity

Information is neutral, but people’s reactions to information are rarely neutral. To assess testing information, you must take into account people’s emotional defenses. (Page 59.)

7 How to deal with defensive reactions

Take people’s emotions into account, try to understand them and resolve the problems caused by them. (Page 66.)

8 What makes a good test?

You’ll never know for sure whether your testing was done well, but there are many ways to know or estimate if it was done badly. (Page 72.)

9 Major fallacies about testing

Learning to recognize a handful of major fallacies about testing could eliminate half the gross mistakes project managers make. (Page 81.)

10 Testing is more than banging keys

To qualify as a test, an action has to seek information that will influence action, whether or not it involves banging on keys. (Page 90.)

11 Information intake

Intake is an active process. You are not a victim, having data put into you, but are at least potentially in control of what you take in. (Page 101.)

12 Making meaning

It is up to human beings to attach meaning to data they take in, and each person does so differently. It’s best to keep in mind that there are many possible interpretations of the data. (Page 113.)

13 Determining significance

Our emotions carry information about how important things are. If we pay attention to emotions, listen and address important matters before unimportant matters, we’ll be doing the best we can with the data we have. (Page 124.)

14 Making a response

If a project hasn’t been managed well before testing, most good responses will no longer be available. In many cases, there is no response that will save the project - except starting over and doing it right from the beginning. (Page 134.)

15 Preventing software testing from growing more difficult

There are intrinsic system dynamics that make testing and fixing take longer as products grow larger and more complex. (Page 140.)

16 Testing without machinery

There are many ways of testing without involving computers, but no way of testing that doesn’t involve using brains. Test early and often; use all the brains you can muster. (Page 151.)

17 Testing scams

I’ve used several testing tools. I’ve contributed to the development of one. I have many years of experience with tools. I am very suspicious of tools making promises. There are a lot of tools that are claiming they have some special super-power, magic or can read your mind. These days they frequently have AI/ML in their name or description.

Whenever you’re desperate to clean up the bugs and ship a product, you’re vulnerable to a variety of testing scams that promise quick, painless relief. (Page 160.)

18 Oblivious scams

When we want so much for everything to go well, it’s all too easy to inject our fantasies into our data. (Page 168.)