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
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):
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.
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.
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.
Here we try to uncorner corner cases.
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.
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.