Testers punished for testing...or are they???

Hi All,

This came up from an interesting discussion I was having with a friend (tester). He was happy because he was able to get the software working so that he could run tests on it the next day. I felt a little awkward with the happiness expressed and so delved into his happiness to find out that

• He was happy because he would not go to work in shifts (night) for testing, because he was able to get it started by EOD.
• He was happy because he shall be able to run the tests as per the schedule defined.
• He was happy because he could start testing.
• He was happy because he could send a report to his manager about the test status as scheduled.
• He was happy because he could find bugs faster, since other members of his team have not got the software to work yet.

Well, there’s more to it and then came an interesting story. Two testers were asked to test 2 different features of a printer. During upgrade of the software, one of the testers removed the n/w cable connected and this crashed the printer. The printer had to be sent for repair. The tester was asked to come in the night shifts, and would share the other tester’s printer to complete his testing.

Fantastic, isn’t it a real motivation for testers, see what this event had impact on the testing team. I couldn’t take this incident out of my head and thought a lot about it.

• Was the tester punished for testing? (Tester could had removed the cable intentionally or not, that’s a different scenario…my friend did not had the information about it)
• Why was the tester not appreciated for crashing the printer?
• Why was the tester viewed as some one who halted testing, wherein he had found one of the most important defect.
• Was there a specific document available to the tester that he was not supposed to remove the cable while upgrading?
• Even if a document specified not to remove the cable, the tester shouldn’t have ever tried it?
• Why do managers feel that running tests are more important than crashing the system?
• Why sufficient number of hardware (printers) not available for testing, this makes me wonder “crashing the printer was never anticipated”?
• Does customer want a tested product which could still crash?

When, I put across some of these questions to my friend and I got loads of excuses like resource crunch (not “human” but “hardware”)/budget/time to deliver/you are not being practical/those are invalid scenarios and finally “you suggest a solution to this”.

Well, testers provide information, what “one” (stake holders) makes out of it is not the tester’s headache. And so “or are they” got added to the title. Hence “Testers punished for testing...or are they???

Please feel free to disagree with me, challenge me, discuss with me, by posting your comments. Also, feel free to reach me at sharu.b@gmail.com.

Disclaimer: All the blogs shared by me are my ideas, my thought, my understanding of the subject and does not represent any of my employer’s ideas, thought, plans or strategies.

Comments

Madhukar Jain said…
Hi Sharath,

Your post is very nice.You have touched a very sensitive issue which makes testers no longer testers.
I am with you on these points.

Keep posting your experiences.
Madhukar
Thanks for the kind words Madhu. The reason why I am a little skeptical about such topics is people actually see it more as “cribbing” rather than an “issue”. This to me is very surprising.

Regards,
Sharath
Asu's said…
Things are still the same.
I've been asked to do a lot of LOAD testing. Many rows on database tables got locked. And I became the villain.
Though I enjoy that too.
Thanks for this nice post.

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

What do you do when you find a bug?

Regression Checks + Regression testing = Regression testing?!