Be Critical But do Not Criticize: 99 Ways Workshop #17

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #17: Be critical but do not criticize - Kim Knup

As testers, we have to be the one's to point out that something is broken, inoperable, or isn't working the way that it is intended. It's important, but it often makes us the "downer" of the group. We (software testers) seem to always be the one's bearing bad news and telling people that "their baby is ugly". OK, that's a bit extreme, but the fact is, we are hired to point out when things don't work the way that they were designed to.

While I'm not going to say "never criticize" or "just be nice and positive all the time", it is entirely possible to give status updates, share findings, and discuss bugs without being cruel or obnoxious.

Workshop #17: Think of RIMGEA when discussing issues or problems

This comes straight out of the BBST Bug Advocacy class. As a software tester, my mission is "to find and share information effectively so that stakeholders can make appropriate decisions". By getting out of the business of deciding if something I see is "right" or "wrong" and presenting it as "here is what I see, what do you think we should do about it?", I change the tone of the entire conversation. I'm sharing findings, not assigning blame.

The information we provide to our stakeholders can be improved by using RIMGEA. It's a mnemonic that stands for:

Replicate: Make sure that any issue I am trying to report is something that I can recreate. Use a count if it's something easily reproducible (5/5 times) or if it's something that will only happen a small percentage of the time (1/5 times, for example).

Isolate: Can I get to the minimum number of steps to show how or where a problem occurs?

Maximize: What are ways that I can show that the issue in question has a particular scope? Is it minor, or does it relate to something much larger? Can I flesh out the issue so that the full impact can be seen?

GEneralize: Does the issue in question occurs in only a tiny, isolated spot, or if it's something that can occur in a broader and more general way?

"And say it clearly and dispassionately": Here's where "be critical but do not criticize" really comes into play. State the facts. State the steps to get to the problem. State the issue you are seeing. State what you would expect to see. State what heuristics you are using to come to the conclusion that the issue is an issue. Leave personal feelings or comments out of the conversation entirely.

Bottom Line:

It can be all to easy to say "hey, why did you introduce this bug into the system?" Flip it around and think about how it feels each time you have heard someone say to you "hey, how come you didn't find that bug?" The fact is, programmers and testers do not want to release bad software. Both groups work together to release the best product possible. Approach reporting issues from the perspective that "we are all in this together" and practice the skills within RIMGEA. This will go a long way to ensure that testers are seen as positive contributors and not antagonists.