RIMGEN – a bug investigation framework for better reports

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.