Ever noticed what do you do between finding and reporting a bug?

Reporting a bug right away, just after you found it might not be the most useful thing you can do. Quite a statement, huh? And you are probably not even doing that. What.. how? I’ll tell you through an example that happened to me a bit ago at work, then show you the more theoretical thought. Watch yourself doing this.

My team refactored a part of our application, now using javascript and there was a shopping cart involved.  I was curios how it will react to the biggest numbers can be typed in when I found a bug. Multiplying really big numbers got the cart frozen, it seemed. I pressed F12 to see what’s going on behind the scenes. It wasn’t only because of big numbers. It was a digit overflow, because of a precision error in javascript (which then of I quickly learned about: http://www.w3schools.com/js/tryit.asp?filename=tryjs_inaccurate2) Aha! Then I thought: how else this could be a problem? This lead to me adding some pretty normal-looking number which then would cause the same problem, freezing down the cart. Called the developer over and didn’t even need to say much.

Why any of this matter? Because reporting a bug that surfaced 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 we will deal with in 2038!” and might be rightfully so. But showing them that the same bug causing the same effect can be reached by multiplying 25.89 by 3 makes the bug get fixed in no time.

I used a mnemonic to help me to go from finding a bug to reporting, coined by Cem Kaner (http://kaner.com/?page_id=11): RIMGEA – later modified to RIMGEN by testing folklore. This is how I RIMGEN-ed this bug:
R is for Replicate: to reproduce the bug on demand. You don’t want to use words like “sometimes” or “looks like” in your report. Before anything I got confident with the bug, that it’s not only my hallucination and the shopping cart got really frozen in case of the biggest numbers that input field for the price can take in.
I is for Isolate: to bring down the number of steps to the minimum. You want to clearly see what is causing the bug. This is where I found out that it’s not only the big numbers, but the javascript precision error. After this it was too easy to show the bug.
M is for Maximize: to show how harmful a bug can be. Probably biggest part of the story I just told you. I went for freaking people out with a frozen shopping cart and a confused and frustrated user.
G is for Generalize: to bring the thing back after maximizing, finding all the places and ways that it can be a problem. Never liked the term “corner case”. But if you use it: this is de-cornering your corner case. This time this has happened naturally as no one asked if this applies to other shopping carts in other shops. No one dared.
E is for Externalize: to make it seen, heard by telling every important person about it. Probably the one that applies to in-house testers the least, although it happened to me before that my findings got buried, either I missed identifying those important people or failed to inform them because of the way I was reporting. It would have been hard this time, though.
A or N for And use Neutral tone: being dispassionate and not forming an opinion helps avoiding blame-culture and finger-pointing. A bug report is a piece of information without any emotion or judgement. What you think or expect of a behavior is not exactly the most relevant part of the product development. It takes some time to really live by it, but very liberating after you have this insight.

 

I made these photos. It shows, doesn’t it? But the photos are taken about postcards, sketched and made by Altom (https://altom.ro/) Levi (https://twitter.com/leventebalint).

Original sighting of the RIMGEA mnemonic: http://www.testingeducation.org/BBST/bugadvocacy (Lecture 6) and other posts on it’s usage https://www.google.com/search?q=rimgea