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


6 thoughts on “Ever noticed what do you do between finding and reporting a bug?

    • Levi

      Very nicely explained my good sir!

      One observation/comment: I always thought of Externalize as trying to find reasons for fixing the bug that is “external” to the team and the stakeholders you report your bugs to.

      Unfortunately I couldn’t find a good real life example of this, but a fictional example would be if you were an engineer working on Google App Engine who found a bug and externalized it by saying that it affects the way Snapchat sets up their servers. (Snapchat = a mobile app external to your team/company which has its infrastructure built on Google App Engine)

      But I guess telling any and all stakeholders about a particular bug that might affect them could get you allies in getting the bug fixed sooner rather than later :).

      P.S. I be convinced to send you a unicorn postcard too 😀 (it’s not part of the “collection” per se, but it seems to be very popular among conference attendees)


  1. tvk

    Nice post!

    I have one correction, though:

    The “precision error in javascript” is a general planned behaviour of floating point numbers in digital technology. For example such a tame number as decimal 0.1 couldn’t be precisely represented in binary system with finite number of digits. It’s 0.000110011001100110011… (25.89 is also similar.) When you multiply with it, the inaccuracy is also multiplied. Sometimes it’s OK to have this inaccuracy, sometimes it isn’t. For example when calculating amounts of money it’s not OK. For the latter case, the solution is for using other kind of number representation than floating point.

    It’s always useful to test some too big, too small numeric values, but also ones which couldn’t be represented precisely when converted to binary floating point numbers.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s