Perfect Software and other illusions about testing by Jerry Weinberg
If you haven't heard of Jerry Weinberg then nows the time to start putting it right, he's been writing books for decades, mostly on quality and testing but also covers consultancy and pyschology.
He says he wrote this book as he could see so many people suffering due to their unreasonable expectations and fallacious models of software testing
Small book ( 180 ) pages that can be easily read in a couple of evenings -unless you stop and think about some of the issues that are raised in which case the book can take a long time
He raises - and tries to answer - the usual questions about testing that are still being raised now
Why do we bother with testing when it just seems to slow us down ?
Why cant we build it right in the first place ?
Do we have to test everything ?
Why not just test everything ?
What is is that makes testing so hard ?
Why does testing take so long ?
Is perfect software even possible ?
Why cant we just accept a few bugs ?
Typical questions that every tester and test manager is either asked or has asked themselves
In the book he tries to explain what is behind these questions in his usual entertaining style.
Each chapter ends with a summary and common mistakes - going through the common mistakes can be a good exercise to tick off how many of them you have made and how many you have experience of
Right from the start he explains how a customer can test a program without even installing it - he reads a review which says it wont run on the OS the customer has.
Onto the testing process - testing provides information. Sometimes it can produce too much information - there is a great example of how testing might unearth a defect but product manager decides not to fix it, customer finds the defect, sues, gets the companys records and finds they knew about the defect but didn't fix it...
The chapter on Meta-Testing is excellent and relates 14 case stories where the client was unable to see the forest for the trees. For example the test manager complaining about the performance of the bug database when more than 14,000 bugs had been logged - working out why there were so many defects might perhaps be more important than worrying about the performance...
Jerry has had a long career in the industry and worked in everything from embedded systems, slot machines, spaceship control, dating services and has found one thing in common with them all - the quality of management seems to be the distinguishing factor between success and failure. How many projects are in a rush at the end ? How many of these claim that is the nature of the industry ? How many managers choose their processes to postpone testing until the end - as testing is the first time that they can no longer pretend that things are going well
Does he provide any answers ? Yes - try to keep things small, build incrementally and reduce the number of bugs going in.
And be aware of all the information around you and try to make use of it
Summary
Anyone who has been in the industry will recognise the stories and mistakes presented in this book. Far too many ideas to make use of right away but could be used as and when the situation arises. Also useful as a check to make sure you're not falling into the common mistakes that he lists
Book Link Here
He says he wrote this book as he could see so many people suffering due to their unreasonable expectations and fallacious models of software testing
Small book ( 180 ) pages that can be easily read in a couple of evenings -unless you stop and think about some of the issues that are raised in which case the book can take a long time
He raises - and tries to answer - the usual questions about testing that are still being raised now
Why do we bother with testing when it just seems to slow us down ?
Why cant we build it right in the first place ?
Do we have to test everything ?
Why not just test everything ?
What is is that makes testing so hard ?
Why does testing take so long ?
Is perfect software even possible ?
Why cant we just accept a few bugs ?
Typical questions that every tester and test manager is either asked or has asked themselves
In the book he tries to explain what is behind these questions in his usual entertaining style.
Each chapter ends with a summary and common mistakes - going through the common mistakes can be a good exercise to tick off how many of them you have made and how many you have experience of
Right from the start he explains how a customer can test a program without even installing it - he reads a review which says it wont run on the OS the customer has.
Onto the testing process - testing provides information. Sometimes it can produce too much information - there is a great example of how testing might unearth a defect but product manager decides not to fix it, customer finds the defect, sues, gets the companys records and finds they knew about the defect but didn't fix it...
The chapter on Meta-Testing is excellent and relates 14 case stories where the client was unable to see the forest for the trees. For example the test manager complaining about the performance of the bug database when more than 14,000 bugs had been logged - working out why there were so many defects might perhaps be more important than worrying about the performance...
Jerry has had a long career in the industry and worked in everything from embedded systems, slot machines, spaceship control, dating services and has found one thing in common with them all - the quality of management seems to be the distinguishing factor between success and failure. How many projects are in a rush at the end ? How many of these claim that is the nature of the industry ? How many managers choose their processes to postpone testing until the end - as testing is the first time that they can no longer pretend that things are going well
Does he provide any answers ? Yes - try to keep things small, build incrementally and reduce the number of bugs going in.
And be aware of all the information around you and try to make use of it
Summary
Anyone who has been in the industry will recognise the stories and mistakes presented in this book. Far too many ideas to make use of right away but could be used as and when the situation arises. Also useful as a check to make sure you're not falling into the common mistakes that he lists
Book Link Here
Replies to This Discussion
-
Permalink Reply by Anna Baik on -
Phil,
Many thanks for this review. As you say, it's a short book. It's also written in a very engaging, easy to read style (not a dry and dusty tome, this one). I like this, because I think it may have a rather higher chance of getting read by recipients, and I'm pretty sure that this will turn out to be one of those books that people press into colleagues'/clients' hands, begging please, please, read this before the project staggers on any further.
It's also a bit of an "ouch" book to read, which is good. By which I mean, I'm reading through it saying "ouch, seen that one. Ouch, seen that one too. OUCH!! I do that!" I somewhat regret not having post-its to hand when reading - it would have been good for me to mark up pages which I really ought to bear in mind.
Definitely one to re-read, I think. And suitable for pretty much everyone involved in a project.
Anna
Find Us Elsewhere
Nice Things
Bloggers
© 2010 Created by Rosie Sherry
