Defect Tracking Life Cycle

[Click on the image for better view]

1) Create Defect: Defect created by the developer while coding.
2) Discover Defect: Defect discovered by the tester while testing.
3) Enter Defect: Reporting the defect using any defect tracking tool.
4) Triage defect: Defect to be assigned to the developer.
5) Debug Defect: If the reported bug is a valid bug it is fixed by the developer.
6) Verify Defect: If the defect is invalid or if it is fixed by the developer then it is once again verified by the tester.
7) If the tester is satisfied by the fix the defect is closed.
8) After verifying if the tester is not satisfied the bug is reassigned and the cycle begins from step 4.
9) The closed bugs are retested during regression testing, if the defect is found again the bug is reopened and the cycle begins from step 4.

Basic fields entered while reporting a defect:

1) Defect ID: Unique ID assigned to the defect(System generated).
2) Defect Summary: Summary of the defect. A one line description that best represents the defect.
3) Assigned to: Assigning the defect to the developer to whom it is concern. This is set by the test lead generally. However if the tester is provided with the module wise developers list, then the tester could update the “assigned to” with the developer names.
4) Severity: Severity of the defect: critical, high, medium and low. This field is set by the testing team based on how sever the defect is and how quickly it need to solved.
5) Status: new, open, fixed, deferred, rejected, reopen, retest, closed, closed – rejected, closed – deferred, closed - duplicate.
6) Module/components: The component or module where the defect is found.
7) Build # / version #: Specify in which build the defect was detected.
8) Priority: Possible values –high, medium, low to be set by the business / development lead for the development team to prioritize the work for the defects added.
9) Attachments: For better understanding of the bugs tester need to attach the screen shot of the defect.
10) Description: Detailed description of the defect. It should provide defect description, reference data, prerequisites (if applicable ), steps to recreate, expected result, actual result, note to refer the attachment section if attachments are enclosed.
11) Fixed reason: The change made to fix the defect. This is done by the developer.
12) Rejected reason and closed – rejected reason: The reasons for rejecting the defect: non reproducible, work as designed, acceptable as it is, test error – not a defect, change / discrepancies in spec. This is also entered by the developer.