The Book in Three Sentences
There is no perfect software. Testing provides information. Most people you work with will know little about testing.
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.
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.)
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.)
I would like to thank @thcipriani for reviewing the article and a lot of advice on how to make it better.