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.

7 habits software coders wish the testers had

In my tenure as a tester and a test manager, I've worked with both types of settings where:

1. my company provided testing as a service to some development firm, so testing team was the service provider and the coding team was the client.
2. my company developed the product itself, so the testers were a part of SDLC team

Interestingly in both cases the coding teams had similar wish list for testers. Here are some common comments and how we can do something about them:

1. Good functional coverage: This is the first, most basic and a must-have requirement. Everyone – coders, managers, clients, all stakeholders – expect you to understand requirements inside out.
1. Make sure you question each line of requirements documentation, find positive as well as negative scenarios to test.
2. Test from each stakeholder’s perspective. Cover most user scenarios.
2. Test environment to resemble end user’s setup as closely as possible:
   1. I’ve seen more than one case when the testing was done well but the environment on which the system was used at the user’s end was not well replicated. Result? Disappointments and wasted  efforts! So beware.
3. Early reporting of defects:
   1. Coders wish the testers would tell them about a lurking defect as quickly as they have found it (so that they can fix it soon). That does not mean testers should should “I’ve got one” each time something unexpected happens. No. You should definitely take your time to dig deeper, isolate your findings, find possible causes of the problem (and probable solutions, even? Why not?!). Just don’t wait till the last moment to fling a defect over the wall when the product is about to roll out.
4. Adequate information in defect reports:
   1. A good defect report consists of all the info required to isolate and fix a defect, in a succinct, crisp way.
   2. Here your skills of observation are going to be utilized the maximum. Mention the exact scenario(s) when something failed. Mention your test environment. Did you have any network services or antivirus program running when the system stalled? When you executed a file more than 2 GB did you get a crash? Paint the exact picture.
5. Surrounding testing while closing defects:
   1. Verifying and closing defects is another crucial activity, that is often overlooked even by experienced testers and that results in dollars lost. One trick I tried while closing a defect was to try and replicate it again. If I fail after reasonable number of attempts, the defect is verified closed.
6. Performance numbers for products / websites:
   1. Coders more often than not rely on you to understand the health of the system they are building. Set aside time and make sure you perform load, stress testing. Do your numbers and report how good, bad or ugly your system is. After all you might have given the best UI features, the coolest animation and stuff on your web page, but if it takes forever to load your users will be turned off. So, get serious about reporting these numbers.
   2. Make sure you also make your managers aware of the importance of these readings, so they can plan time for performance testing, finding related defects and getting issues fixed, system optimized.
7. (Last but not the least) Respect for other person’s work:
1. One of my greatest lessons from serving s/w industry is that “it’s the man that maketh the machine”. And men (and of course women, too) have human flaws. Egos. If you spent your 8 waking hours of a day away from your family (and TV) to write a web page, no matter how sloppy, you’ll still be expecting others to look up to it with awe. Ok. I agree there’s a bit of exaggeration there. But get the point clear. Don’t make defect counts proportional to the amount of respect you show for others. Be diplomatic when it comes to announcing faults in someone else’s work. “Do unto others what you would have others to do unto you.”

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.