Defect Report

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

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.

While reporting the bug to developer, your Bug Report should contain the following information

1. Defect_ID - Unique identification number for the defect.
2. Defect Description - Detailed description of the Defect including information about the module in which Defect was found.
3. Version - Version of the application in which defect was found.
4. Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.
5. Date Raised - Date when the defect is raised
6. Reference - where in you Provide reference to the documents like. requirements, design, architecture or maybe even screenshots of the error to help understand the defect
7. Detected By - Name/ID of the tester who raised the defect
8. Status - Status of the defect, more on this later
9. Fixed by - Name/ID of the developer who fixed it
10. Date Closed - Date when the defect is closed
11. Severity which describes the impact of the defect on the application
12. Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively

Reporting Defects Effectively

Be specific:

1. 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.
2. 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’.”
3. 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:

1.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:

1. Do not make subjective statements like “This is a lousy application” or “You fixed it real bad.”
2. Stick to the facts and avoid the emotions.
3. Reproduce the defect:
4. 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.

Useful Links:
Bug report article/eng
Bug report video tutorial/rus
Bug report video tutorial/eng
Bug, Bug report video tutorial/arm