Here's a real life story-
The Clallenger Spacecraft was launched on 28th-Jan-1986, but unfortunately exploded 73 seconds post liftoff. There has been a lot of research that has gone into finding the actual reasons for this crash. Much of the research of what went wrong with Challenger launch focuses on the lack of communication between NASA and Morton Thiokil, Inc (MTI). MTI was the contractor responsible for the component that failed during the launch. Almost 2 years before the fatal launch, MTI became aware that there could be a problem with O-ring, a sealing component that prevent hot gases from escaping the solid rocket booster and burning a hole in the fuel tank which was the physical cause of to this disaster. The engineers at MTI documented this problem and insisted that the further testing needed to be done to determine the reliability of O-ring. Upon further testing they confirmed that the O-ring was not reliable, particularly when temperatures dropped below 53 degrees. The question is-
Why then was the Challenger given the go to launch on that fateful day, when the temperature at launch time was 36 degrees, well below safety margin ?
One strong possibility, the researchers say- the people around the table were afraid to express their doubts or even to ask questions that they had determined before entering the room that morning that they would ask.
Source for above excerpt: The book- "Leading with questions" Author: Michael Marquardt
The above story caught my imagination because it was a very strong co-relation with Software Testing real life situations. The very fact that Engineers at MIT had documented the problem in advance was not enough to avert this disaster.
- How many times have you as a tester been in a situation or unknowingly gets into a situation wherein you feel your responsibility ends as soon as you log a defect ?
- Arent testers the owners of the defect- right from the time its logged till the time it is reported as fixed and later verified ?
Another point of view regarding the above excerpt-
- This story again shows that there is a vast difference between passive communication and an active, impact communication. What was required in above situation was the courage by the person who knew about the problem to raise his voice "loud enough" to be heard. And probably the person who tested was contented with the fact that he has already documented the problem and his job is done.
Conveying the bad news is an art that every tester has to master. And this is not as easy as it may seem. It does require a rare courage and will to stand by what is right and communicate with tact to all the stakeholders.
You must learn from the mistakes of others. You can't possibly live long enough to make them all yourself.
- Samuel Levenson
Are Software testers listening, and learning ?
Keep testing passionately!