Across different projects development methodologies, one thing that remains prime important is how the defects are reported. From my experience, finding defects is as important as reporting them. Often reporting defects is more time consuming than finding one. Sometime I have been able to find defects in seconds but reporting the same it has taken me more than couple of minutes if I am trying to generate more information on how exactly the defect happens and in what circumstance it does not.
Most of the defect reporting tools be it HP ALM / QC or Mantis, BugZilla, Jira or plain old excel sheets allow team members to follow the template. The template itself has drop downs which allows testers to select the version they are testing, environment they are testing, how severe the defect is, what the priority is and place to write summary and then description of the defect. There could be other mandatory and non-mandatory fields/columns etc. We all would agree that the two most important sections to be filled out are
1. Summary of the defect
2. Description of the defect

Here lies the simplicity or we may say art of writing the defect such that the person reading it is able to understand without someone explaining the defect to him in person or in phone.
a) What exactly the problem is
b) Where is it happening
c) And is there enough information for the reader of the defect to reproduce the defect.

Many a times there are lengthy discussions between the developers and testers to understand what the defect really is.
Let us take some sample examples from real life defects reported. Please note that these may be reported in a little hurry and I am keeping the spelling mistakes as it is. The comments would be more from what exactly is missing the report.
The template used had the following important fields/columns

Bug-Reporting-Aditya1
Good thing about the template is that it does tell which browser it was tested on, which screen/page the defect was and type of defect. We are not going to go into details on what are other things that could have been there in the template but look at some of the defects reported in terms of summary written.
Defect sample 1.

Bug-Reporting-Aditya2

We do understand that the defect is in the registration page, it is a functional defect and the severity reported is 2, but the summary says. “Duplicate registration allowed”
What do we really understand from this report.
It is missing basic information like
– What exactly is the duplicacy
– What was the sample data used

It is a clear case where the developer would re-send the defect back to tester to put in more details or there would be a call to discuss this defect.
Similar defects
Defect sample 2.

Bug-Reporting-Aditya3
What is the expected functionality of search that is not working correctly ?
Defect sample 3.

Bug-Reporting-Aditya4

What exactly is the validation that is missing for the primary and secondary email ids

Defect sample 4.
Reported by one person

Bug-Reporting-Aditya5
Same defect reported by another person

Bug-Reporting-Aditya6
If we read the defects together we will really understand what really is happening. The first one is giving generalization and the second one is giving information which is too specific. On its own either defect is not a good one, we would need information from both the reports to really understand the exact symptoms behind the report.

Take a look at the same defect reported by the 3rd person.

Bug-Reporting-Aditya7

This one is the best among the all, it has summary neatly written, description is detailed yet concise enough and the screen shot reference is also provided.
50 to 60% defect reported in my experience lack similar important things.

The art of defect writing is to really being disciplined in the way anyone report the defects. Following would help
1. Read your defect twice – check for simple mistakes like spelling and grammar mistakes
2. Do not rush into submitting the defect, provide enough information like
a. The behavior exhibited. It should be such that people reading the behavior understand what exactly the problem is.
b. Give sample data used – like on entering – this is what is displayed
c. Attach screen shot for even better understanding
d. Getting the first few defects reviewed by a peer tester to see if he/she understands to the level you want to explain

By putting in extra few minutes these issues can be resolved to a very high extent. Defect writing and reporting is one of the most important areas in testing life cycle and is one of the most neglected areas as far as review and training process is concerned.
Let us get agile by getting this sorted out first.

 

This article was published in our April 2014 Edition.

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Bug-Report-software-testing.jpg?fit=390%2C255&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Bug-Report-software-testing.jpg?resize=150%2C128&ssl=1Aditya GargArticlesBug Report,Testing ArticleAcross different projects development methodologies, one thing that remains prime important is how the defects are reported. From my experience, finding defects is as important as reporting them. Often reporting defects is more time consuming than finding one. Sometime I have been able to find defects in seconds but...