In previous article we discussed about Defect Life Cycle. Now we will see why it is essential to write a qualitative Bug Report. Each Bug tracking tool have its own format of Bug report but there are mandatory sections will always be there.
Effective bug report leads to higher rate of resolving defects.
Let’s take an example of Live Scenario to understand why meaningful report is so necessary.
– During the testing of a functionality Tester has found one defect. Now he reports that defect with poorly written insufficient information and assigns to one of the developer. The developer not knowing anything about the behavior of this defect tries to understand and reproduce the same on his machine. As the steps are not clearly defined in the defect, he fails to reproduce it and therefor he assigns the defect back to Tester with the status “Not A Defect” or “Can Not Reproduce“.
– Now Tester has to make him understand the behavior of the defect. He will do it by either updating the description of the defect report or he will just go at developer’s desk and reproduce the defect on his machine.
– Imagine the time has spent on single issue just to re-produce on developer’s machine. If the Tester would have provided the detailed steps and summary in the first place than they could have avoided wasting extra time spent on re-work.
Below mentioned are some tips for writing an effective Bug Report :
1) Defect Title – Meaningful & Self-explanatory
Title of any defect should be written in such way that anyone can get high level idea of the defect’s nature just by reading these one or two lines.
Sometimes a good title gives everything you need to know about the defect and yes it saves much of your time.
2) Don’t forget to mention Precondition (If Applicable)
Some defects are not straight forward to re-produce. You have to perform some steps / scenarios before executing steps to re-produce the defect. In such cases, developer won’t be able to reproduce the defect if precondition is missing.
Example : In an e-commerce website you find a defect on the discount applied feature. Now let’s say this defect is re-producible only for few categories of product.
So while writing bug report you need to mention all those categories in the Precondition.
3) Steps To Reproduce the Defect – Mention all steps in detail (Without Fail)
Starting from accessing URL of the application, you must mention all the steps and conditions leading to occurrence of the defect. Do not write as a summary, it’s boring to read and less informative. Keep each condition / step in separate point with proper numbering.
4) Do not worry about Defect Count. Keep each defect discrete
Combining multiple defects into single one will surely save your time while reporting but later it will lead to the confusion. let’s say you have combined 3 defects (occurring on the same page) into single one. Now developer has resolved one of the issue but remaining two are still open. You can’t close the defect until any single issue mentioned is not resolved.
In some scenarios, long discussions happen on the defect through comments. In such cases, managing multiple defects in single report may lead to mess.
5) Do not introduce Business Scenarios, Just pass suggestions
While testing an application you might feel some scenarios / business flows should be added or removed (ofcource for the betterment). Do not raise them as the defects, but yes such cases can be reported as Suggestions. Just pass the information and let the Business do the judgement.
6) Grammatical Mistakes – Avoid
Be very precise while writing a Bug report. Try avoiding fancy words. Keep it simple and more understandable. You don’t want the developer to get confused and come to you for explanation. There are many Spell check add-on for each browsers which can help you in avoiding spelling mistakes.
7) Severity & Priority of the Defect
Each and every defect must be having appropriate value of Severity and Priority. Severity decides the impact of the defect on the application & Priority gives information on how quickly the defect should be fixed. Developers will focus on resolving defects having Highest Priority and severity first.
8) Dependency on other defects
Some defects are having dependency on other issues, meaning you can not verify and close the defect unless and until other one is not resolved. You will face situations like: A defect is assigned to you marked as Fixed, but you are unable to verify that because of the step you need to perform to check itself is having an issue. In such cases, keep the defect “On Hold for verification” and link with the dependent Bug number. Don’t forget to provide proper comment like : “Issue#1 is dependent on Issue#2. Once Issue#2 is resolved and assigned for testing, QA person will be able to verify and close Issue#1”.
9) Nature of Occurrence
Some defects occur in random manner. There are not exact steps to reproduce and you can’t track the occurrence behavior as well. For such defects you can mention something like this :
“This defect is re-producible on random basis with the ratio of 4-5 / 10 times.”
10) Do not forget to mention Build number / Version # / Server details in Bug Report
During the software testing life cycle, your project goes through different servers : Dev Server, QA Server, Pre-Production, Live etc. So whenever you are reporting any defect, mentioning these information is must :
– On which Build version you are doing testing and Defect is reported
– On which Server issue is found, resolved and closed.
Other than these scenarios listed above, if you want to share anything please let us know. Thank You!!