Make your defect reports stand out in two steps

Defect reporting is as much art as it is science. You have to convey just the right info, with the precision of a scientist for approvers to approve your defect, for coders to easily understand & replicate it and then to fix it.

Can't stress enough on how important it is for your defect report to be good, so that it's chances of being fixed increase. Think about your defect report as something that's not much different from applying to a bank for a grant to finance your business venture. Only if the bank sees value in your proposal - it clearly understands what problem are you trying to solve for which market sector (and how, of course), - will it consider to give you monies.

Step 1. That gives us point#1 of this post. The artistic part. One essential point your defect report needs to have is a business case.

I am not talking about straightforward crashes or unexpected error messages. They will be fixed without needing any convincing. This is about requirements level issues or feature requests or some portions that need to be changed in the functional workflow. I've seen a lot of such defect reports termed as "Fix in later release" (read never-fix), which could have really added value to the system had they been fixed.

The common ingredient missing  from these reports was - they failed to convince the managers / approvers of their value.

So, how do you make a hard-to-refuse case for your defect. First step is to do your homework. Answer some of the questions to yourself to get you started.

1. Why do you think something needs to be changed?
   • Is there a conflict between two requirements?
   • Is the current way cumbersome? Can some of the steps in a lengthy workflow be reduced?
   • Is the current way compromising on security? Or performance?
2. Research your competitors. Are they doing things in an easier, more intuitive way? Are there better ways of achieving your objective? Faster? Simpler?
3. What benefits are your suggested changes offering to the end user? More accuracy? Ease of use? Freedom to use your application on multi-platforms (web / desktop / mobile)?
4. Think of yourself as the end user. How would you like the application to be? Why?

Once you get answers to some of the questions here, state it out clearly. Once. Cut the clutter.

(If you think you need help with concise writing, check out this book. Written by author Robert Fiske, this one is definitely for keeps with over 10,000 alternatives to lengthy phrases. Here’s where you can get it:

Step 2. Alright. Moving on to the science part. The one that will help coders to understand, replicate and fix your defects - adequate information. And how do you get this info across quickly and effortlessly? (Yeah, I count typing in 500 words of how-to article in the description for the coder to be able to replicate a crash as serious (and wasted) effort!) Use Media! As the old adage goes, "a picture is definitely worth a thousand words". Show the readers how to replicate an issue, don't tell.

Grab any one of the screen capture software tools around. You can try:

1. SnagIt from Camtasia (Love it! It’s so simple to use, and provides output which has people questioning me how I did it so well?)
2. Captivate from Adobe (Heard good things about this, but never tried)

Here are some ideas how these tools can help your organization in terms of productivity and you as a tester:

1. Use any one of these software tools to capture the video of steps to replicate the defect.
2. You can enhance the videos by adding annotations. Text bubbles for remarks, highlighted circles, arrows etc. are some of your choices.
3. Tools like “Click! Recorder” from GlueSoft can even prepare the list of steps for you alongside recording the video. How cool is that?
4. If your steps are not so complicated and it’s a straightforward defect, you can use these recorders to capture just the still image / text from error message or complete object information. Often this gives a very good hint to the coders on what could have gone wrong.

Easy? And so very effective!

There you go. Try these tips to experience the change for yourself. Don’t forget to drop a line and let us know your thoughts.

Thank you for reading!

Enjoyed reading this article? You’ll like receiving more tips and testing related information in your e-mail. Please subscribe by clicking here. You’ll also be helping me in reaching my goal of having 1000 subscribers by Dec 2011. You have my word for no spam and complete privacy of your information.