Effective defect reporting

Written by Vishal Shah

One of the aims of software testing is exposure to hidden defects. But only finding a defect is not enough, once you find any defect; you need communicate it through the whole team or to the concern person (for e.g. Business analysts, managers, developers, other team members, or client) in order to grab their attention towards it and get it resolved.
This process of communicating a defect or to notify a defect is called as defect reporting.
There should be some centralized place/database where reporter can file the defect and others can have access of it. To solve this purpose, many dedicated defect tracking tools are available; you can choose one of them as per your need.

Who all are involved in defect reporting process?
We can broadly categorized the roles, as Reporter, Reviewer, Developer and QA/Tester
Reporter is the one who reports the defect (can be a QA, can be a Client). After the defect is reported, Reviewerreviews it, reviewer can decide whether the defect is valid or not? If required reviewer can change severity and priority of the defect, even a reviewer can reject a defect. Once the defect is accepted it gets assigned to Developer. Developerfixes the issue and finally Tester confirms that the defect is fixed or not.

How to report a defect EFFECTIVELY?
Sometimes it happens that; though the defect is reported, developer needs to ask for further explanation to the reporter. One of the reasons is, reporter knows the defect but fails to communicate it properly or fails to provide sufficient information or sometime information provided is ambiguous.
Defects can be a complex or can be simple, but it is always very important to write a good defect report. As we saw that many persons are involved in defect life cycle, so a good defect report will be effective and easier for everyone to solve the problem. Ultimately it will help to save problem solving time.
Before reporting defects make sure that –

• It is a defect and you can reproduce it
• It is not machine specific
• You are testing the correct version of the application
• Same defect has not already been reported

Reporting a Defect –
Different defect tracking tools might have different fields or different conventions.  Attributes like Project, Version, Type, Severity, Priority, Summary, Description, Steps to reproduce etc. are mandatory and very important for reporting a defect are present in almost every defect tracking tool.
While reporting a defect –

• Select correct project name
• Select correct version
• Specify the Type whether it is a defect or enhancement request
• Choose right Severity and Priority based on the conventions followed by your organization.
  • Severity will express the impact of the defect on the application
  • Priority will decide the order in which the defect will get addressed and resolved. Based on this priority it will be decided which defect is more important and need to fix first.

• Summary – Summary can be a single liner description of the problem. Try to summarize the problem in a meaningful line so that just by seeing the summary one should get fair idea what the defect is about.
  • Summary should be clear and specific
  • Should not be ambiguous for e.g. “Accepting invalid data”. This is example of bad summary. It does not talk about what data, on which page, when exactly it happens.
• Description – Elaborate the summary. Describe the problem in very simple and meaningful sentences. No Need to use very hi-fi, decorative words. Try to describe in the form of instructions (do this, do that, click here etc)
• It will be very helpful if you can provide detail steps to reproduce the defect, so that it will help developer to find and fix the problem.
• Always try to provide test data (where required) with the steps.
• If possible provide the root cause of the defect, it will save developers’ time and efforts
• Also mention the expected result and actual result in the description or steps
• It always will be good practice to upload evidences (screenshot or error log file) with the defect. If possible highlight the exact problem in the screenshot
• Don’t club or mix two defects, always file a separate defect report for each defect

Example – Lets us take a simple scenario for example
The scenario is, Tester is testing a user registration page and found that Birth date field is accepting future date.
Now let’s see how the effective defect report will look like

All these are very simple yet very important techniques to note and if you follow these techniques, I am sure it will make your defect report much effective.