Purpose of a defect report is multifold in any organization. Defect reports are used to
- Alert software programmers about the defect and gives them sufficient information to find root cause and fix the problem.
- Provide information to technical writers who are writing troubleshooting, known limitation etc.
- Provide starting point for the next release
- Add test cases in the regression suite for next release.
According to IEEE 829, A good defect reports should be simple, understandable, reproducible, legible and non-judgmental.
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 hig 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.
Hope this template was useful for you. You can also visit test plan Here.
In every organization defects are reported or tracked in a defect tracking system
Don't miss any article:Get it by E-mail