Investigate With RIMGEN
When you find what seems to be a bug, don't report it immediately. Improve your upcoming bug report by using RIMGEN, a widely used mnemonic by Cem Kaner1.
RIMGEN helps turn one observation ("it crashed") into a strong, reproducible, well-scoped, high-value bug report.
In a Nutshell
Replicate - ensure you can reproduce the bug. Ideally, on two different machines if time and resources allow
Isolate - Determine the shortest number of steps to reproduce it. Perhaps 4 is enough, and not 6 as you originally thought.
Maximize - Do follow-up testing to see if you can trigger a bigger failure or find a more serious problem.
Generalize - See if the problem affects more people in more ways than you originally considered.
Externalize - Describe how the bug will affect stakeholders.
Neutral - neutral tone in the bug report. No blaming, no sarcasm, 100% professional.
Below is the complete explanation of RIMGEN as seen on the BBST website.
R – Replicate
Make sure the failure is reproducible by anyone who follows the steps in your report. Add clear information, steps, or conditions.
I – Isolate
Identify the shortest number of critical steps necessary. Take out any unnecessary steps from the bug report. The goal is to end up with the shortest number of critical steps.
Ask yourself:
What are the critical conditions to reproduce this bug?
Are any of the steps unnecessary?
Is more than one failure described? (Rule of thumb: One failure per report)
M – Maximize
Find a more serious problem underlying the one initially found.
Here are four types of follow-up testing focused on severity:
Vary your behavior – change what you do as you test
What happens if you do this instead of that?
Repeat the test many times
Change something related to the sequence of tasks in the test
Change values of variables in the test or combine them with other variables’ values
Change something related to the failure (tasks, sequence, data)
Vary the options and settings of the program – change settings of the application under test,
Vary data that you load into the program – different startup files or other data not directly involved in the test
Vary the software and hardware environment.–e.g., operating system, peripherals, external software that interacts with this application
G – Generalize
See if the problem affects more people in more ways than you originally considered.
Uncorner your corner cases (show it fails (or doesn’t) under less extreme conditions)
Show it fails (or doesn’t) on a broad range of systems (configuration dependence)
Check whether many different paths will lead to the same failure
Check whether the bug is new to this version – One more kind of generality: How new is it?
Check whether failures like this already appear in the bug tracking system
Check whether bugs of this kind appear in other programs
E – Externalize
Highlight who will be affected by the bug and explain how the bug will affect them.
Add information beyond test results:
Comparisons with competitors
Predicted criticisms from the press
Usability weaknesses
Lost value because it’s too hard to achieve a benefit that programmers don’t think is so important
Predicted support costs
Other implications for sales, support, legal, etc.
N – Neutral Tone
The bug report is easy to read and understand, and the tone used is neutral.
References
1 Black-box Software Testing (BBST): https://bbst.courses/rimgen/
Last updated