Defect Report Template
A good defect report might have following sections.
Headline
One line description of the defect. Remember, A good headline will always be clear, related to the defect and give some hints on how critical defect could be.
Product
In most cases defect tracking system is used for more than one product. So specifying appropriate product and version is very important.
Component
Products are normally very complex, and can be divided into components. A defect report containing proper information about component can help managers in assigning it to appropriate person.
Defect Type
Defect type could be, functionality, specification, regression, UI etc. This classification can be used to analyze how defects are distributed in the system.
Priority
Priority is the impact of defect on business. This field gives an indication of the impact of this defect on business. In some organizations, testers do not specify priority, It is defined my manager or triage team members.
Severity
Severity is the impact of the defect on the product. For example if you hit five keys together and your product crashes, it is a very severe defect. But its priority is probably low because normally people might not hit five keys together. Now consider that the company logo is not proper on the splash screen. From severity point of view it is not severe as it is not crashing application or blocking user from using the application. However, it is high priority as it is affecting organization's image.
Environment
Proper information about your test execution environment should be present. For example, information about platform, databases, run times everything should be included in your defect report. This information helps development team in reproducing the defects.
Steps
All the steps should be specified clearly. You should not assume that programmer will understand this. Programmer might be looking at your defect report when are not around to explain. Your steps should be clear enough for a novice user to follow and reproduce or verify the defect .
Attachments
Whatever additional information is needed for the defect, should also be attached. This additional information could be logs generated by system, application etc. It could be screen shots or any other thing that might help developers in reproducing the defects.
Comments
If you have any additional comments on the defect, you should specify it clearly. For example if you observe/think that defect is related to some other defects filed in the same component with little variation. You should specify that.
Tags:
defect report,
Manual testing
Leave a comment