Reporting a bug right away after finding it might not be the most useful thing you can do. What.. how? Here is an example and the theory behind it.
Looking at the bug itself, not only what it can cause
My team refactored a part of our application to start using javascript. I was curious how it would react to the biggest numbers that can be typed in when I found a bug. There was a shopping cart involved and multiplying really big numbers got the cart frozen, it seemed. I pressed F12 to see what was going on behind the scenes. It wasn’t only because of big numbers, but instead it was a digit overflow, caused by a precision error in javascript (which I then quickly learned about: http://www.w3schools.com/js/js_numbers.asp) Aha! From then on I could easily reproduce it. I wondered, how else this could be a problem? This lead to me adding some pretty average-looking numbers which then would cause the same problem, locking down the cart.
Why does any of this matter? Because reporting a bug that came after multiplying 999999999999.99 by 99 might make a developer or product manager say “Who would do such a thing?” or “Let’s put it on the backlog and deal with in 2032!”, and rightfully so. But showing them that the same bug with the same effect can be reached by multiplying 32.99 by 3 ensures that the bug will be fixed in no time.
Can you think of a way to do something similar? Here is where I got the idea from
To go from finding the bug to reporting it, I used a mnemonic to help me. RIMGEA was coined by Cem Kaner (http://kaner.com/?page_id=11) and later modified to RIMGEN by testing folklore.
R is for Replicate: to reproduce the bug on demand in order to avoid words like “sometimes” or “looks like” in the report. Or to see for myself that I wasn’t just hallucinating.
I is for Isolate: bring down the number of steps to the minimum, so you can clearly see what is really causing the bug. This is where I found out about the precision error.
M is for Maximize: show how harmful a bug can be, probably biggest part of the story I just told you. It means trying to show the worst thing that can happen as a result of this bug.
G is for Generalize: bring the thing back after maximizing; try to broaden the scope of the bug and find all the places that it can be a problem. I don’t like the term “corner case”, but for the sake of argument, this is de-cornering your corner case.
E is for Externalize: make it seen and heard by telling every important person about it. Even in-house testers can be caught burying what is not dead.
A or N stand for And use Neutral tone: a dispassionate approach and not forming an opinion help you avoid blame-culture and finger-pointing. A bug report is a piece of information without any emotion. What you think or what behaviour you expect from others is not exactly the most relevant part of the product development. It takes some effort to really live by it, but I found this a very liberating insight.
Postcard courtesy: https://twitter.com/leventebalint
You can find the original sighting of the RIMGEA mnemonic here: http://www.testingeducation.org/BBST/bugadvocacy (Lecture 6) and other posts on its usage by searching: https://www.google.com/search?q=rimgea