A bugging story on Testers’ Credibility

A little over a year ago, I earned a reputation of reporting maximum number of severity 3 and 4 defects in the team. This appeared bad at the time as compared to other testers who reported severity 1 and 2 defects. Unlike these testers, I reported all the defects because I did not want anyone questioning my credibility as to why I did not find/report a defect. Ok, agreed that I was high on ego.

I often questioned myself “Am I really as bad as my colleagues think I am?”. I filed as many critical issues as other testers did. Ah! Turns out I wasn’t the crash specialist in the team. And we go gaga over crash specialists and worship them like Gods at times. Don’t we? Naturally, I received feedback that I need to focus on finding more defects of high importance and less of low importance (which wasn’t as direct as I wrote here).

Here I was, a tester who strongly believed that higher the number of defects I reported, the better I was as a tester. And now, people tell me I am not a good tester. I was devastated. I cried. I was angry. A day later when emotions settled down, I started to think about the feedback practically. I relooked at the summary and category of defects that I had reported until then. A total of 575 defects! Categories varied from functionality to usability to performance to user experience to cosmetic errors.

What did I do? I…………
1. Reported trivial issues with higher severity at a time when there were limitations on time and resources.
2. Ate up significant time of programmers on defects irrelevant at the time by coaxing them to take a look at the reports immediately after I reported them.
3. Reported low severity defects by assigning high severity consciously. I remembered Dr. Cem Kaner say "The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed". I miss-interpreted what Cem said of a good tester in this context.
4. Happily explained every unimportant defect in the bug scrub meeting.
5. Did not know that this wasn’t a workable approach. By the way, no one told me until the next appraisal cycle.

What did I change? I now………
1. Report important defects quickly by informing programmers informally. While they provide buddy fixes or potential fixes, I report the defects and close them after verification.
2. Don’t pester programmers to fix unimportant defects when there are important ones to be cared about.
3. Report trivial issues by assigning exact severities instead of pushing them one level up :D.
4. Create a separate backlog milestone or queue for trivial defects to be looked at a later point of time. But report them anyways.
5. If programmers work in the same office building as mine, I walk up to them and discuss the defect and share my findings. This helps me learn new things about the feature or the defect and also sets the context for the programmer. This also helps the programmer understand my concerns with regard to the defects.

Magic Trick
MIP heuristic helped me get over my defect mania. Mention in passing (aka MIP) is to refer to someone or something briefly while talking about something else. Eg. During the interview, Kavita mentioned in passing that her dad had also been involved in publishing. I MIP bugs that don't matter as much as critical bugs do. I MIP trivial bugs to programmers who crib 'No user would do that' often. I MIP bugs that are of lesser importance at the time, but may be important a little later, maybe customer asks for it after sometime, but all that he is bothered about now is to get rid of the crashes or blockers.

I struggle with defects that are of low severity, yet important enough to be fixed. I MIP such defects. I walk over to the programmer, talk a little about that feature and say ‘Hey, you know what? I just saw this behavior while testing this feature. What do you think of this?’. The programmer agrees most of the time. When you give control to the programmers and ask them what they think of a defect, they will be open about it. If testers are going to push the programmers by nudging or embarrassing the product (which is their baby), they will hate you. 'How dare you tell me that my baby is born with deformations? I wish I could kill you right now right here'. I do believe that in addition to mipping, reporting defects in defect tracking system for internal tracking and closure is important. You never know when your manager will ask ‘how could you miss such a simple defect?’. Most managers don’t realize that complete testing is not possible. Mip your defects, yet report them all.

Happy Mipping,
Parimala Shankaraiah