The 5 stages – a guide for testers to the stages an engineer goes through when you tell them you’ve found a bug.

October 29th, 2014

I didn’t write the following. It came a QA manager of mine, John Crook, some years ago when I first started out as a tester. I went on to be a developer for some time before returning back to my tester roots so I know these words to be the truth…

The 5 stages – a guide for testers to the stages an engineer goes through when you tell them you’ve found a bug.

1 – Astonishment

Typical reactions that identify an engineer being in this stage are phrases like “but that code is bullet proof” or “that can’t have happened because that code hasn’t changed for months”. During this stage the idea that there may actually be a problem starts to slowly sink in, this can take from seconds to days depending on the engineer’s ego. If the engineer lingers in this stage you can help guide them through more quickly by suggesting that if there is a bug it’s almost definitely someone else’s fault.

2 – Accusation/Anger

When moving to this stage the engineer is beginning to believe that maybe there is a product defect at issue here. However, if there is, it is almost certainly someone else’s fault. Typical phrases to look out for are “well, if that’s happening you better go an see so-and-so about it because he’s probably doing such-and-such wrong” or “that’s not how it’s supposed to be used – it wouldn’t crash if your tests were better”. You should seize this as an opportunity. Agree vigorously with the engineer that it’s surely someone else’s fault. Carefully worded agreement at this stage can propel the engineer into the final stage. However in many cases there are still two more stages to pass through before analysis is done.

3 – Assumption

During this stage an engineer will assume they know exactly what the problem is and exactly which line of code needs changing to fix the problem. This can sometimes happen before you’ve even finished explaining what the problem is. Phrases to look out for are “yes, we know about that, we discovered the problem ourselves and fixed it this morning” or “yes, it’s a C++ compiler issue and I need to change my code to work around Microsoft’s problem, come back in 5 minutes and I’ll have a new DLL for you”. It can be tricky to deflect engineers from this path once they have it in their head they “know” what the problem is. If you’re quick off the mark you can try pointing out how their assumption does not fit the facts however this can have varying degrees of success. Often there is no option but to redo your tests with the new DLL and go back to the engineer when the product defect still shows up.

4 – Acceptance

During this stage a few neurons finally connect and fire. The engineer realises that he will have to look seriously at the problem. This is good but you’re still not quite out of the woods yet. Watch out for delaying tactics like “OK, maybe this needs looking at but I’m working on this new work which is far more important, I’ll try to look at it later in the week”.When this happens it can often help to praise the engineer in some way – make out that they are so brilliant they could probably fix the thing in 5 minutes and that would help the product immensely.

5 – Analysis

Finally they will look at the log files and data you have collected and do some analysis of the facts.

Posted in Uncategorized | | Top Of Page

Comments are closed.