RIMGEA

Heyhey!

Last November I took the BBST Bug Advocacy course and even though it was quite a lot more demanding than Foundations, somehow I managed to pull it off. Unfortunately I don't have the time to write full recap of it. Instead I'll concentrate to one of the best mnemonics since SFDIPOT, namely RIMGEA.

Bugs are an integral part of testers' work and the information we produce, and RIMGEA is a kick-ass heuristic of how to communicate bug related information to stakeholders. It's copyrighted by Cem Kaner and dissected as follows:

• Replicate it
• Isolate it
• Maximize it
• Generalize it
• Externalize it
• And say it cleary and dispassionately

There are some blog posts about this subject, but I wanted to present my take on it. So let's get to it then.

The first element of RIMGEA is Replicate it. Quite simply it's about replicating the situation where the bug presents itself in order to instruct others to replicate, and possibly fix it. Chances are that if you're not able to replicate it, no one else will either. But don't let it stop you if you're not able to replicate a bug. Raise discussion about it and create confidence to your judgment in others by communicating your potential findings. Others may have better viewpoint to the subject and they can help you to replicate the bug. For example developers can tweak debug logs to give more information, customer support can give input on common problems, etc.

Isolate it goes deeper into the replication bit. Isolating the situation where the bug presents itself means taking into account all the relevant variables that lead into bug presenting itself. Now, I've experienced beautiful bug reports during my days, written ones being just one dimension of this. I've produced thousands myself too, many not that beautiful. There have been long, elaborate ones and there have been short, concise ones. The more the merrier doesn't apply here, because if you produce lenghty reports and/or you produce them by numbers, you also produce corresponding amount of overhead.

Bram Bronneberg puzzled
@ Belgium Testing Days 2014

I often train the isolation bit to people via games. Puzzles work beautifully. I ask people to solve a puzzle and write down the sequence how they solved it. Then I can give these instructions to someone who doesn't know anything about this particular puzzle and ask him/her to solve it by using these instructions. That way I can find out if the author managed to pinpoint the relevant variables. Some people dazzle me with awesome, long answers (thanks Adina ;) and some with elegant, short answers (thanks Huib ;). In all cases this is an effective coaching exercise, and I want to thank Kristjan Uba for teaching me this.

Insanely effective way to help others to replicate what you've done is to show them what you did. Screen recorders and keyloggers work beautifully, but do remember the isolation bit in them too. I was in a project where a group of 40 testers recorded their screen activities from their test sessions, and that created a huuuuge pile of video material. Timestamping helped us to pinpoint the interesting bits from that mass, but still terabytes over terabytes of video material is a bit crazy.

Moving on. Maximize it means that you try to dig up something worse. You can vary your behaviour, program options/settings, data or the environment in order to replicate the bug with more severe results. Or you can dig deeper for more info about the root cause that may trigger something way worse than the effect you first came across with. For example I once tested this mapping software where you could zoom in and out by entering scale values. I noticed that the scaling functionality had no minimum or maximum boundary, and that I could zoom in and out indefinitely. As such the bug was minor, but it lead me to investigate that the whole program lacked minimum and maximum boundary handling. The bug grew to be a massive risk.

Ok, it was something that should've been noticed before a single line of code was written, but hey... Hire me earlier! :)

I've given these to many :)

Generalize it goes well with maximize it. It means that you try to come up with more general effect on your bug. A broader range. A bug that can be replicated in all configurations, environments, usage patterns, etc. is more serious threat than a bug that cannot. "Works on my machine" is the antithesis of this approach.

Maximize and generalize it are basically about focusing on impact and propability, the cornerstones of conventional risk analysis. Externalize it brings third dimension to it: Focus is put on context. Now this is something that from where I stand separates the really good testers from the mere good ones: Considering the value or impact of the bug through the eyes of stakeholders. Tester weighs on bug cost, how it effects company image, does it affect maintainability (or other quality dimensions), to whom its a bug/feature, and ultimately how much does it "bug" those who matter. Considering heuristics such as HICCUPPS gives even more professionalism to bug reporting, and credibility to the tester who reports the bug.

Maximizing, generalizing and externalizing it all work beautifully as sales leverage. Bug advocacy. You can use this leverage to create credibility for these bugs and to yourself. Dig deeper, dig wider and come up with new information about the risks people are dealing with.

Very professional.

And say it cleary and dispassionately! Practice your English, Finnish or whatever language you're providing the information in. Practice your writing skills AND your speaking skills. Practice giving feedback, and getting it. Ultimately practice your communication skills. And DO NOT piss people off by blaming them, laughing at their mistakes or in general bringing negative emotions in play. Emotions tend to divert focus from the most important: the information you provide. Even if you find the same bug for the Nth time, be cool and report it.

Well, that's RIMGEA. A kick-ass heuristic of how to communicate bug related information to stakeholders. Before wrapping up, I wanted to handle one more thing... You might've noticed that I used "the bug presents itself" a lot. Time after time I have to remind people that testers do not break the software. Ok, there are interesting viewpoints on this subject, but I still do believe we do not break software. If anything, we break illusions and delusions and we are experts in finding if something is broken.

That's it! If hope you liked this post. If you did or did not, please comment and create discussion.

Cheers,

Sami

PS: Instead of just delivering bad news to developers all the time, every now and then it's good to tell them how awesome they are. A friendly word can do more for quality than hundred bug reports. A hug can do even more... ;)