DEFECT REPORT, also known as Bug Report, is a document that identifies and describes a defect detected by a tester. The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it.
ISTQB Definition
- defect report: Documentation of the occurrence, nature, and status of a defect.
Defect Report Template
In most companies, a defect tracking tool is used and the elements of a defect report can vary from one tool to the other. However, in general, a defect report can consist of the following elements.
| ID | Unique identifier given to the defect. (Usually, automated) |
| Project | Project name. |
| Product | Product name. |
| Release Version | Release version of the product. (e.g. 1.2.3) |
| Module | Specific module of the product where the defect was detected. |
| Detected Build Version | Build version of the product where the defect was detected (e.g. 1.2.3.5) |
| Summary | Summary of the defect. Keep this clear and concise. |
| Description | Detailed description of the defect. Describe as much as possible but without repeating anything or using complex words. Keep it simple but comprehensive. |
| Steps to Replicate | Step by step description of the way to reproduce the defect. Number the steps. |
| Actual Result | The actual result you received when you followed the steps. |
| Expected Results | The expected results. |
| Attachments | Attach any additional information like screenshots and logs. |
| Remarks | Any additional comments on the defect. |
| Defect Probability | Probability of the Defect. (See Defect Probability) |
| Defect Severity | Severity of the Defect. (See Defect Severity) |
| Defect Priority | Priority of the Defect. (See Defect Priority) |
| Reported By | The name of the person who reported the defect. |
| Assigned To | The name of the person that is assigned to analyze/ fix the defect. |
| Status | The status of the defect. (See Defect Life Cycle) |
| Fixed Build Version | Build version of the product where the defect was fixed (e.g. 1.2.3.9) |
Reporting Defects Effectively
It is essential that you report defects effectively so that time and effort is not unnecessarily wasted in trying to understand and reproduce the defect. Here are some guidelines:
- Be specific:
- Specify the exact action: Instead of just saying “Generate the financial report.”, you might want to say “(1) Go to Reports page. (2) Select ‘Financial Report’. (3) Click ‘Generate’”
- In case of multiple paths, mention the exact path you followed: Do not say something like “If you do ‘A and X’ or ‘B and Y’ or ‘C and Z’, you get D.” Understanding all the paths at once will be difficult. Instead, say “Do ‘A and X’ and you get D.” You can, of course, mention elsewhere in the report that “D can also be got if you do ‘B and Y’ or ‘C and Z’.”
- Do not use vague pronouns: Do not say something like “In ApplicationA, open X, Y, and Z, and then close it.” What does the ‘it’ stand for? ‘Z’ or, ‘Y’, or ‘X’ or ‘ApplicationA’?”
- Be detailed:
- Provide more information (not less). In other words, do not be lazy. Developers may or may not use all the information you provide but they sure do not want to beg you for any information you have missed.
- Be objective:
- Do not make subjective statements like “This is a lousy application” or “You fixed it real bad.”
- Stick to the facts and avoid the emotions.
- Reproduce the defect:
- Do not be impatient and file a defect report as soon as you uncover a defect. Replicate it at least once more to be sure. (If you cannot replicate it again, try recalling the exact test condition and keep trying. However, if you cannot replicate it again after many trials, finally submit the report for further investigation, stating that you are unable to reproduce the defect anymore and providing any evidence of the defect if you had gathered. )
- Review the report:
- Do not hit ‘Submit’ as soon as you write the report. Review it at least once. Remove any typos.
Last Updated on September 5, 2020 by STF