Wow, my random selection of lessons to post/learn about did the right thing by me. For those of you that know the book, this lesson is the last one before the chapter on Automating Testing. If I had landed a few pages to the right, I would be in trouble… Automation is not one of my strong points! That’s the beauty of what I’m doing though, I’ll be forced to focus on it soon enough. :0)
Lesson 101: When you decide to fight, decide to win!
To give those that haven’t read the book some context, this is in the chapter on Bug Advocacy.
Firstly (while we’re on the subject), an awesome read guaranteed – http://www.kaner.com/pdfs/bugadvoc.pdf from Cem Kaner. Bug Advocacy awesomeness from one of the masters.
“Even if you don’t win every appeal (you won’t, of course), you should develop a reputation that every appeal of yours deserves to win.” A notable quote from lesson 101.
This lesson deals with bug rejection. We’ve all had a bug rejected at some stage or another. By a developer (most common), but also by a Project Manager, or a Business Analyst, etc. So the idea is that you don’t just send back the same bug report without adding more detail to back up your claim/argument/debate/etc. Pretty easy concept right? Maybe not. Ever seen two people going at it on TV (Cops, or Jerry Springer for example) and all they are doing is repeating the same line over and over again. So frustrating to watch! So frustration to see in a bug report!
It’s kind of like negotiation 101 (pardon the pun) – Always go in prepared.
Do you need to add more information in relation to how to reproduce the bug? Do you need to talk to marketing to add more weight to your report? The lesson even goes on to mention looking at the media for stories on similar bugs out there! Now that would definitely add more to your report. This is one that I had never thought of until I read the book. I think the book purchase was worth it even if this was the only thing I learned (it wasn’t of course).
Something that as worked well for me before is appealing to the particular developer that rejected it. If you have that relationship built, then use it. All I had to do was add a bit more information on how it would impact the end user in a particular scenario, knowing all along that he was a user of that particular scenario. I was confused at the time as to why he hadn’t thought of that impact himself, but that is just an awesome example of the differing mindsets for the tester and developer.
This kind of information is really useful in bug triage meetings as well, even if the extra information isn’t written in the report itself. Having said that I think it’s a good idea to capture the extra information somehow, and this is usually done easily by adding to the bug report after the triage meeting.
So next time you’re sending back a rejected bug report, think about how your case may better appeal to the person who needs to fix it, or will make the decision to have it fixed. While you’re at it, think about this while you’re producing a bug report for the first time. May save a rejection, which in turn will save loads of time and possibly frustration.
Happy bug reporting people!