• 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.

• 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 and requirement verification checklist in this section.

Your feedback is important to us. Please provide your feedback.