Defect Reporting

Defect Reporting

Defect Reporting

During Test execution If Test Engineers/Testers find any mismatches, send Defects Reports to Developers

Sample Defect Report Template

1) Defect ID: Unique No or Name

2) Description: Summary of the defect

3) Feature: Module / Function / Service , in these module TE found the defect

4) Test Case Name: Corresponding failing test condition

5) Reproducible (Yes / No): Yes -> Every time defect appears during test execution
No -> Rarely defect appears

6) If Yes, attach test procedure:

7) If No, attach snapshot & strong reasons:

8) Status: New / Reopen

9) Severity: Seriousness of defect w.r.t functionality (high / medium / low)

10) Priority: Importance of the defect w.r.t customers (high / medium / low)

11) Reported bug: Name of Test Engineer

12) Reported on: Date of submission

13) Assign to: Name of the responsible person in development team -> PM

14) Build Version ID: In which build, Test Engineer fount the defect

15) Suggested fix (Optional): Tester tries to produce suggestion to solve this defect

16) Fixed by: PM or Team Lead

17) Resolved by: Developer name

18) Resolved on: Date of solving By Developers

19) Resolution type: check out in next page

20) Approved by: Signature of Project Manager (PM)

Defect Age: The time gap between “reported on” & “resolved on”

Defect submission process:

Defect Status Cycle:

New Open / rejected / deferred close reopen

Deferred => Accepted but not interested to resolve in this version

Defect Resolution:

After receiving defect report from Testers, developers review the defect & they send resolution type to Tester as a reply

01) Duplicate, rejected due to the defect is same as previously reported defect
02) Enhancement, rejected due to the defect is related future requirement of customer
03) H/w limitation, rejected due to the defect raised w.r.t limitation of H/w devices
04) S/w limitations, rejected due to the defect raised w.r.t limitation of S/w Techno
05) Not applicable, rejected due to the defect has no proper meaning
06) Functions as designed, rejected due to coding is correct w.r.t to designed doc’s
07) Need more information, not (accepted / rejected) but developers requires extra information to understand the defect
08) Not reproducible, not (accepted / rejected) but developers require correct procedure to reproduce the defect
09) No plan to fix it, not (accepted / rejected) but developers want extra time to fix
10) Fixed, developers accepted to resolve
11) Fixed indirectly, accepted but not interested to resolve in this version (default)
12) User misunderstanding, need extra negotiation between testing & development team.

Types of defects:

01) User Interface bugs (low severity):

1) Spelling mistakes (high priority)
2) Improper alignment (low priority)

02) Boundary related bugs (medium severity)

1) Doesn’t allows valid type (high priority)
2) Allows invalid type also (low priority)

03) Error handling bugs (medium severity)

1) Doesn’t providing error message window (high priority)
2) Improper meaning of error message (low priority)

04) Calculations bugs (high severity)

1) Final output is wrong (low priority)
2) Dependent results are wrong (high priority)

05) Race condition bugs (high severity)

1) Dead lock (high priority)
2) Improper order of services (low priority)

06) Load conditions bugs (high severity)

1) Doesn’t allow multiple users to access / operate (high priority)
2) Doesn’t allow customers accepted load (low priority)

07) Hardware bugs (high severity)

1) Doesn’t handle device (high priority)
2) Wrong output from device (low priority)

08) ID control bugs (medium severity)
1) Logo missing, wrong logo, Version No mistake, Copyright window missing,
Developers Name missing, Tester Name missing

09) Version control bugs (medium severity)
1) Differences between two consecutive build versions

10) Source bugs (medium severity)
1) Mistake in help documents – Manual support

You may also like...