Selling Bugs - Time is in short supply. If you want to convince the programmer to spend his time fixing your bug, you may have to sell him on it. (Your bug? How can it be your bug? The programmer made it, not you, right? It’s the programmer’s bug. Well, yes, but you found it so now it’s yours too.)
Why do some testers get a much better response from development than others? Part of the answer lies in the way a defect is logged. Following a few simple rules can smooth the way for a much more productive environment. The objective is not to write the perfect defect, but to write an effective defect that conveys the proper message, gets the job done, and simplifies the process for everyone.
· Use Simple language to describe, neither exaggerate nor undertone it.
· Remember always defect is bad - not the “Programmer”.
· Never offend the efforts of the programmer. You can use sober language to describe the attributes. This will take care that the programmer’s efforts are respected.
· Keep It Simple & Straight but be concise.
· You are not writing an essay or an article. Keep your target audience in mind while writing the bug report.
· Make defect report understandable to developers, fellow testers, managers, or in some cases, even the customers.
· Click the: Add Comment button before adding any comment to the bug. The comments should be added while changing any characteristic of a bug like “Status”, “Assigned To” etc.
· Never mention any personal opinion or remark that is insulting to the developer – be absolutely professional. – For e.g. – “please fix this bug first thing in the morning. As usual, even this has failed.“
· Add a comment describing a simpler set of replication steps. Make sure these are clear and accurate
Here are various sections that should be mentioned while raising a defect:
Defect Summary: A one clear and simple line that describes a defect.
Problem Statement: This should be a semi detail information around what the defect is. This explains the defect in two to three lines – or may be four.
Steps to reproduce: This should be a step-by-step description of how to reach to the page / application state where the defect is present. Keep in mind that who so ever fixes the defect will start thinking about it from the steps you write. Ideally this should start from login and step by step reach to the final page. Some testers like to create a separate section like “Pre Requisites” which should be achieved before re-producing the defect.
· Start from a known place (e.g. boot the program) and
· Then describe each step until you hit the bug.
· NUMBER THE STEPS. Take it one step at a time.
· If anything interesting happens on the way, describe it. (You are giving people directions to a bug. Especially in long reports, people need landmarks.)
· Describe the erroneous behavior and, if necessary, explain what should have happened. (Why is this a bug? Be clear.)
· List the environmental variables (config, etc.) that are not covered elsewhere in the bug tracking form.
· If you expect the reader to have any trouble reproducing the bug (special circumstances are required), be clear about them.
Actual Result: This details out of the actual state of the application
Expected Result: This section details for what you were expecting.
Screen shot: It’s a good practice to take screen shots of defect page in a word document and point out the exact field / place where you want to lay stress on. Provide screen shots wherever required.
Note: Add “Notes” after the description if you have them. Typical notes include:
· Comment that the bug won’t show up if you do step X between step Y and step Z.
· Comment explaining your reasoning for running this test.
· Comment explaining why you think this is an interesting bug.
· Comment describing other variants of the bug.
Reproducible: This is used only if the defect management tool has no separate section to capture it.
· You may not see this on your form, but you should always provide this information.
· Never say it’s reproducible unless you have recreated the bug. (Always try to recreate the bug before logging the defect)
· If you’ve tried and tried but you can’t recreate the bug, say “No”. Then explain what steps you tried in your attempt to recreate it.
· If the bug appears sporadically and you don’t yet know why, say “Sometimes” and explain.
· You may not be able to try to replicate some bugs. This is fine and ok to live with.
Testing Mantra :
The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
Cheers
Anupreet Singh Bachhal
A Testing Novice
asbachhal@yahoo.com
