Wow, it’s been 10 years since this blog post: RIMGEA – 6 approaches to bug reporting. There I wrote about a very useful mnemonic I picked up from a bug advocacy class (it’s more about bug reporting, than loving bugs). Lately, I’m not in a role where functional testing is part of the official R&R. But I think I’m a tester through and through — I still test or review, and I still log bugs or give feedback. And I still care about how bad bug reporting can give testing a bad rap.
So anyways, now’s a good time as any to retouch that post.
RIMGEN (and maybe plus S)
Originally, the mnemonic I picked up from the bug advocacy class was “RIMGEA“. It stood for the 6 factors or approaches to bug reporting which are: Replicate, Isolate, Maximize, Generalize, Externalize, And say it dispassionately. Then there was a suggestion in the comments before and I also found some recent BBST material that made the shift from “A” to “N” to suggest the neutrality in tone. The last letter S was from the comments, with a suggestion to spellcheck. I would generalize it as proofread but RIMGENP doesn’t roll off the tongue quite easily.
Replicate it – Try to replicate the bug.
If you can’t replicate it yourself, then it might be harder to persuade your developer to fix a problem that they can’t see. This also doesn’t only benefit the developer. Somewhere down the line, you or a fellow tester will also need the same information. The replication steps would be helpful in preparing test data or setting up the conditions to test the fix for the bug.
Related Link: How helpful are my bug reports
Isolate it – Limit the steps or the conditions that trigger the bug.
Here you try to narrow down your repro steps or find what exactly are the critical conditions that led to the bug. Here you want to get to the bug in the easiest way possible. You want to rule out factors that have nothing to do with the bug.
Related Link: Bug isolation
Maximize it – Try to trigger a worse or bigger failure.
The bug you find might just be the tip of the iceberg, or a symptom of an even bigger bug. Follow-up tests could help uncover the bigger problem if there is indeed one. For instance, you find a bug regarding the positioning of a button in a modal when you tried it out on mobile. Turns out, if you try it on your laptop browser, the problem still exists. Turns out, other similar modals have a different positioning of the buttons. Turns out, the bigger problem is on the consistency of the modals across your app — and not just with particular modal screen you tried on mobile.
There are various tactics that you can try:
- vary your behavior – e.g., instead of doing A then B, try changing the sequence; or try a different way of doing the task like using a shortcut key instead of the button
- vary your program settings – e.g., there could be program settings that you can toggle on or off or adjust; for browser testing, you can try adjusting the zoom sizes or enable/disable caching
- vary your inputs – e.g., if the bug was encountered when file X was used, try a similar file Y or another file Z
- vary your configuration – e.g., try using a different OS/browser combination
Generalize it – Try to broaden the extent of the bug.
Here we try to uncorner corner cases. We try to find other ranges in which the bug can be reproduced. For instance, we find that a bug occurs when we have 1M records. In generalizing, we try to see if the bug occurs at lower more realistic values or if the 1M records is truly a critical condition.
I find this quite similar to Maximize. But essentially, with both, you are trying to push or find out how damaging the bug actually is in depth (how much does it cascade) and in breadth (in terms of the users and cases it can affect).
Externalize it – Try to see the value or impact of the bug from 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.
As testers, we might also find ourselves focusing too much on the functional specs. The devil’s in the details and zooming in on the details is important. But so is taking a step back and seeing the bigger picture on whether the functionality can actually deliver what the users need.
Neutral tone – Try to write our bug reports as clearly and as neutral as possible.
Having worked in building apps for over ten years, I know that there’s some egos that bruise far too easily. The bug report isn’t really about the people working on the project, so keep it that way. It only has to be about the bug. Keep it on point and add in only what would be relevant to help address the bug.
Related Link: Article: How to report bugs effectively
Spellcheck – Proofread your bug report.
It’s amazing how often people forget to proofread. So when and if you can, just do a quick pass to see there are no glaring errors and to also check if it’s clear enough. Be mindful that the audience of that bug report could possibly be future you, so you’d literally be helping yourself if you write it clearly.
So there. Let me awkwardly close with one of my favorite quotes. It’s one that I often associate with bug reporting.
A problem well stated is a problem half solved.
testkeis 
Pingback: “Is this a bug?” | testkeis