My 5 Biggest Takeaways from the BBST Bug Advocacy Course

by | Syndicated

I recently completed the BBST Bug Advocacy course and am currently waiting to hear whether I passed or failed. I was somewhat freaked out when I got sick (a damn cold) during the exam period and found myself having to reread the questions multiple times before I could figure out what I was supposed to do (thanks to my headache at the time). To add to that, none of the questions I practiced for were in the exam (I reviewed for about a third of them) so the first word that went through my mind when I went through the exam was S***.  I ended up splitting up my answers into multiple sections so that I could actually understand what I needed to do (this turned out to be something the reviewers really liked funnily enough). Enough of my wee rant, below are my biggest takeaways from the course.

1. Irreproducible bugs should still be raised

This was a big one for me. I’ve always thought “What’s the point if I can’t reproduce it?” The thing is, if a lot of people encounter the same bug over a period of time and can’t reproduce it – then they (as a whole) can help gather evidence so that someone can fix it. If these bugs are never raised in the first place, then you can’t gather evidence. It’s worth noting though that you should state that you haven’t been able to reproduce it.

2. Include the impact of the bug

To be honest, this isn’t something I’ve always done – I’d say I used to do it from time to time. But I would really like to get back into this habit as it helps advocate why a bug should be fixed.

3. The Acronym: RIMGEA

Quite a gem in the course. This is a useful mnemonic for bug reporting.
I found a blog that helps explain it clearly:
But here’s an excerpt from the blog (edited for clarity):

1. Replicate it – Try to see if you can replicate the bug.
If you can’t replicate it, it might be more difficult to provide information to the developer and persuade her to provide a fix for a problem she can’t see.
2. Isolate it – Try to limit the steps or the conditions that trigger the bug.
Here you try to narrow down your repro steps or to find what exactly are the critical conditions. Here you want to get to the bug in the easiest way possible.
3. Maximize it – Try to do follow-up steps to see if you can trigger a worse failure.
The bug you find might be just the tip of the iceberg, or a symptom of an even bigger bug. Follow-up tests could help to uncover the bigger problem if there is indeed one. 
4. Generalize it – Try to broaden the extent of the bug
Here we try to uncorner corner cases.
5. Externalize it – Try to go see the value/impact of the bug in other stakeholders’ perspective.
Here we try to go beyond our roles as testers and try to get a sense of the bigger picture. In understanding the value that could be lost, we could paint a more compelling picture of why the bug needs to be fixed in our bug reports.
6. And, say it clearly and dispassionately – Try to have our bug reports as easy to understand and as neutral as possible.
Clarity will make it easier for the dev/triage team to find out what exactly needs fixing and hopefully why it needs fixing. Neutral bug reports will make our work easier to read as opposed to reports that are angry or disrespectful in tone.

4. Credibility Also Influences Whether (or not) Bugs get Fixed

It’s not just about the quality of the bug report itself – but the behaviour of the person who writes the bug report.

5. Write bug reports so that it enables good decision making

This part stood out to me. At the end of the day, I want to help project managers/product managers etc. make well-informed decisions based on the information I provide them. This means, they need to be able to understand the information I provide them. If I’m spending time writing bug reports but they don’t understand what the problem is (and the impact of that problem) then we’ve got a problem