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!
Subscribe to:
Post Comments (Atom)
11 comments:
Hi Anuj
I think that tester's responsibility not at all ends with logging a defect.In my career,i have always taken care of my bugs till the end of their lifecycle and in most cases even after that to underrstand the pedigree.
Nice post.
Hi Anuj,
Read you recent Blog...
Sounds good.. its great to read about.. its even great to write about..
however..
do you really think, that the role of tester would have extended beyond documenting the issue..
I do agree.. QA owns all responsibility of defects.. when a issue is documented.. all that the qa is trying to do is bring it to the notice of his.. higher ups..
from the qa perspective it may be Must Fix kind of issue.. but stake holder may come back and say.. OOOO this is a Edge case.. In the narration you mentioned.. Temp dropping below 53deg.. non-technical decision makers would have come up with a logic “what is the percentage of chances we landing in such a situation..”
I think.. well its my perspective.. to much of risk taking by the management is the concern..
At every project level.. every one is bent upon meeting his/her deadlines..
Specifically non-technical boss.. who does not under stand what it takes to test a feature makes a decision.. and in the process what gets compromised is quality and Testers very desire to test passionately…
May be having sound technical managers is the solution to all this..
well as i said .. its my perspective..
and if u have different opinion..
I agree to disagree with you..
Thanks for the wonderful article though..
Regards,
You have raised a difficult point through your post. It is the question of accountability.
My opinion is as follows. It is true that the tester is the owner of the defect report (as the defect moves through its life cycle). Additionally, it becomes the tester’s responsibility to ensure that “sufficient” testing does indeed take place, ensure that defects are reported accurately, raise the defects appropriately and support the development/ maintenance team resolve the defect. However, I feel that the tester alone cannot be held accountable for an open defect. There are other decision makers e.g. development managers, technical staff, QA, management, client etc. who can exert direct or indirect influence on if and when a reported defect is fixed. Quality is not an individual but a collective responsibility. Having said that, it would definitely help all concerned if the tester continues to request the resolution of reported defects (tactfully, of course), especially so in the case of any serious defect.
Dear Anonymous,
Thanks for your comments and i would have appreciated more if you had mentioned your name as well.
from the qa perspective it may be Must Fix kind of issue.. but stake holder may come back and say.. OOOO this is a Edge case.. In the narration you mentioned.. Temp dropping below 53deg.. non-technical decision makers would have come up with a logic “what is the percentage of chances we landing in such a situation..”
I think this is where the bug advocacy skills and persuasion skills of an engineer come into picture. In my experience, test engineers usually get satisfied and refrain them from thinking beyond technical and functional expertise of a product. Technical and Functional expertise is not doubt important, but as per a popular misconception- it does not constitute everything one needs to know to excel in testing. This is a business side of things that needs to be mastered to improve bug advocacy. If a test engineer can counter the argument like “what is the percentage of chances we landing in such a situation..”, with accurate data points, that can help management drive to fix the bugs.
Of course, this requires a great deal of effort on a tester's part but in the end its just worth it.
Regards,
Anuj
Dear Inder,
Thanks for your comments.
Your point of view regarding Accountability is valid but at the same time i feel that if the "Voice of tester" is loud enough and the noise created is strong enough then it can indeed make a difference.
Again agreed Quality is a collective responsibility but giving information as applicable to the right context is a tester's responsibility.
One thing- if during product go, no-go meetings if a tester has an iota of doubt about the quality of the release, then he/she must speak up. I have seen that in such meetings, even the slightest risk is reasoned out by all the stakeholders. But general tendency is not to raise doubts in such meetings and then grudge that the tester's point was not considered.
Regards,
Anuj
Hi Anuj ,
This is a great post and totally agree to your view point on Test Engineers should own the bug and the responsibility doesn't end after a bug is being logged .
One thing which I would like to focus in this particular case is a major Engineering process flaw happed in NASA / MTI . as mentioned a tester had logged this issue and also conducted more investigation in this problem and found that O-ring was not reliable, particularly when temperatures dropped below 53 degrees. So ideally this issue should be still open ( not closed ) if not then it's a much bigger problem . If Yes Did the team of "Wise" people responsible for release look into the release criteria and validated the exceptions? The point which I would like to bring in here is that in Longer duration projects the Test Engineer who logs a bug will not "Always" have the visibility of what is happening to the product through out the development cycle, So there is a whole lot of responsibility that stays with the leaders to make right decisions and making right call even if the news is bad.
Hi blr venture,
Thank you for your comments.
The point which I would like to bring in here is that in Longer duration projects the Test Engineer who logs a bug will not "Always" have the visibility of what is happening to the product through out the development cycle, So there is a whole lot of responsibility that stays with the leaders to make right decisions and making right call even if the news is bad.
Agreed there can be situations that Test engineers would not have visibility into many thing but point to be taken is that the Engineer can always question...wait...raise the "right" questions in the "right" forums to bring forward his concerns. If any concern is for real, i feel it should not be left until any reasonable explaination is give.
Having said that, i realize that it also has an cultural dependencies. Many organizations (though less) would not have an Open communication culture but i beleive that "Adversity builds up character" and one should strive to do right things in unfavorable situations also.
Regards,
Anuj
I am a software tester. For me a software tester is someone who finds information about the quality of the product.
A software tester does not do any quality assurance. Test doesn't assure anything and hence you can think testing and quality assurance are two different jobs often confused as co-existing ones.
As a tester, I do not think of my job as trying to own or disown a bug but as finding answers for the questions stakeholders have.
Maybe the software that others test have a limited set of bugs for them to own it till it gets fixed but the software that I test have billions of bugs that I have not found. The more time I spend owning a bug the lesser time I have to find other bugs and hence I think it is a bad idea for me to own a bug.
Note that I am saying it is a "bad idea" for "me" and not for others.
Moreover, we never know if a bug is fixed or not because we can't afford to spend an year researching on every bug and do a maximum of 5-6 tests to verify a fix and move on. Not in my experience I have seen tests done by tester for verifying fixes of bugs being sufficient for all kinds of bugs.
If you are instructed to assure quality then maybe you might want to try doing whatever you said above BUT the thing is - Software is invisible When you send an SMS can you ever know how many lines of code and how many functions are being exercised?
What most testers do is to believe whatever they see is whatever in the background. All of this makes the tasks more difficult.
I keep saying to myself, "Pradeep, it is good to dream of doing great things in testing like finding all bugs and ensuring all are fixed BUT understand that your job is to find information about the quality of the product AND you are a human. All humans are fallible"
Surprisingly, people who plant bugs dont seem to be discussing in any forum of owning it as much as testers do.
Michael Bolton said, "I am a character in the story of how a bug got missed" and I think it is powerful to understand that testers are one of the character in the whole story.
The gatekeeper job of quality or bugs and bug fixing is not a tester's job in my opinion.
Hi Pradeep,
Thanks for your comments.
A software tester does not do any quality assurance. Test doesn't assure anything and hence you can think testing and quality assurance are two different jobs often confused as co-existing ones.
As a tester, I do not think of my job as trying to own or disown a bug but as finding answers for the questions stakeholders have
I too agree with this definition of what Software tester is supposed to do in principle. And you have made an interesting observation about a tester not doing quality assurance. I too agree with this but have a point here based on my experience. Most of the organizations that i have been a part of did not have a separate group for "Quality Assurance" purpose and i guess its the same in most of the organization. In such a scenario, it is a well accepted fact that quality is a collective responsibility and each department does their bit to ensure that quality remains a priority. Software testing also moves a little beyond the traditional role (of finding information about the quality of the product). And in such a scenario- to ensure that things are not assumed between the several departments working together with synergy, it is imperative that the communication remains proactive and there are no loose ends left anywhere...that was the message i intended to convey through this post.
Nice Article :)
Hi "THE DEEP",
Thank you for liking the article.
Regards,
Anuj
Post a Comment