After uncovering a defect (bug), testers generate a formal defect report. 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.
Defect report template
In most companies, a defect reporting tool is used and the elements of a report can vary. 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 Severity |
Severity of the Defect. |
| Defect Priority |
Priority of the Defect. |
| 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. |
| 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: Do not say something like ‘Select ButtonB’. Do you mean ‘Click ButtonB’ or ‘Press ALT+B’ or ‘Focus on ButtonB and click ENTER’? Of course, if the defect can be arrived at by using all the three ways, it’s okay to use a generic term as ‘Select’ but bear in mind that you might just get the fix for the ‘Click ButtonB’ scenario. [Note: This might be a highly unlikely example but it is hoped that the message is clear.]
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 types.
and 5 others joined a min ago.
teamques10
★ 68k