Book Review: Lesson Learned in Software Testing

I heard about this book so many times, but thanks to company library it has finally slipped to my hands :)

Lesson Learned in software Testing
A Context-Drive approach
by
Cem Kaner
James Bach
Brat Pettichord

Inspired by Michael Larsen and his book reviews, I decided to write my own book review. I think it will help me with better understanding of this book and also push me to think about it’s content for longer than couple of seconds.

This book consists of advices not only for people in Testing Field but for all who are working around Software Testing and Software Quality.

Chapter 1. The Role of the Tester

Do you agree with below statements ?

- Testers assure the quality
- Testers should be able to block the release
- We have bug-free product
- The product can be tested completely
- Tester should be focused on requirements only
- Programmers are on the opposite site for testers

If you agree with any of above I strongly recommend reading this chapter to see different point of view. Authors present their opinion about many misconceptions regarding role of tester and testing. It's worth to read their arguments and attached examples.
Below couple lessons from this chapter with my own explenation:

"You are headlight of the project"
We don’t drive the project, we don’t make decisions, we are in project to find information about the product and present these information to every stakeholder who is interested in it so they can make better decisions.


"You will not find all bugs"
Authors present their opinion that it is impossible to find all bugs in a product unless your product is very simple or you have limited imagination. During my career I heard sometimes "bug-free software" which simply presents same misconception. We would have "bug-free software" if all the existing bugs were found but we don't have because it's impossible to check every possible place in the product with every possible combination of different circumstances. Even if we have enough resources to achieve this we should still remember the what is feature for someone can be bug for someone else. I like the example which comes from AST BA exam question:

"Suppose we revised a program so that it looked up all display text (e.g. menu names) from a text file on disk, so the user could change the language of the program at any time (e.g. French menu text to Chinese). Suppose too that, because of this change, the new version is much slower than the last, making some people unhappy with it. How we would evaluate this. Is it bug or feature ?"

"Mission drives everything we do"
Having in mind that completely testing is impossible, we should have clear mission on what we are going to achieve with testing. Some example test missions from book :

"Find important bugs fast"
"Prove a general assessment of the quality of the product"
"Do whatever is necessary to satisfy particulate client"

The mission may change from place to place, from context to context and from project to project but still we should have clear guidance for our testing activity.

Alek

P.S.
The initial plan was to create review for each chapter, however I think it's not good idea. The book is packed with so many tips, suggestions and insights that I think that each lesson is worth to review separately. Instead of reviewing all chapters I will try to focus on some of the lessons in later posts