RIMGEA – 6 approaches to bug reporting

Posted on by

I’ve learned a very useful mnemonic from the bug advocacy class on some approaches to bug reporting. Here’s something I had written on the topic with some edits (I just linked to previous write-ups on the same or related topics).

The 6 factors or approaches to bug reporting are:

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.

[Link:  How helpful are my bug reports]

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.

[Link: Bug isolation]

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. There are various tactics that can be tried:

  • 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

4. 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.

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. It is difficult enough to have to deal with a problem in the product, antagonistic reports don’t help as they can only increase the difficulty, cause conflict and discredit the reporter for lack of professionalism.

[Link: Article: How to report bugs effectively]

7 thoughts on “RIMGEA – 6 approaches to bug reporting”

  1. Pingback: Techniques to make exploratory testing even more efficient - ReQtest

  2. Good list and having a mnemonic helps memory. One thing I would expand the description on step 2: Isolate it. It also helps to isolate the conditions that might contribute to the cause. A simple example, for a web app, does the bug happen with alternate browsers?

    Reply

  4. Pingback: Techniques to make exploratory testing even more efficient

  5. Pingback: RIMGEA (2nd ed.) aka RIMGEN | testkeis

  6. Pingback: My 5 Biggest Takeaways from the BBST Bug Advocacy Course – Nicola Lindgren

Leave a comment