Defects Life Cycle

Defect Tracking Management

When a tester finds a defect in software or application defect is opened / created in test management tool like Quality Center, Test Director or IBM Rational. Defects can be manged as follows:

Ø  Tester opens the defect in QC and it will be in ‘NEW’ Status.

Ø  BA reviews the defect whether it’s a “Valid” Defect or “Invalid” Defect.

Ø  In Case of Valid Defects BA makes the Status as “Open” and Assigned to Development Lead.

Ø  Development Lead then changes the status to ‘Assign’ and Assigns to relevant developer.

Ø  Developer will fix the defect and change the Status of Defect to “Fixed”.

Ø  Lead will change the status of Defect to “Delivered to Test”.

Ø  Tester will now test the Defect in “Ready to Test” status.

Ø  If the Defect is fixed then the status will be changed to “Closed”

Ø  If the Defect is not fixed then the status will be changed to “Re-Open” and Step 5 to Step 8 is followed again.

Ø  In case of Invalid Defects BA will change the status to “Rejected” mentioning the reason      for Reject.

Ø  Rejected defect will be verified by tester/test lead. Based on the result defect status will be changed either to ‘OPEN’ or ‘CANCELED’ status

Ø  If the status is changed to “Open” it will be assigned back to BA and If BA is convinced with new comments in defect and also the ‘OPEN’ status, BA can assign it to Dev team/GL, if still they consider it as ‘Reject’ BA need to discuss it with team/GL before rejecting – this is to avoid number of defect reopening iterations

Ø  Dev needs to change defects status to ‘Fixed’ once they fix and required verification is done from their side. All the ‘Fixed’ defects needs to be ‘Delivered to Testing’ environment by Dev after end of each cycle, defects which are Critical/Show Stoppers can be delivered to QA environment at any point of time as hot fix by BA coordinating it with Testing team.

Ø  All the ‘Delivered to Testing’ defects will be verified by QA team during next cycle execution or during dedicated defect verification duration.

Ø  Verified defects will either be re ‘OPEN’ or ‘Closed’ based on the results

Ø  At any case BA can’t change the ‘Severity/Priority’ of the defect by their own, CDM can ask the QA team to change the ‘Severity/Priority’ of the defects by providing required info to testing team.

Ø  If BA rejects defect saying duplicate, duplicate defect number need to be added to comments area of rejected defect

Defect Life Cycle flowchart:

Ø  Fixes of Defects from UAT/Production can be verified by testing team on request/requirement [As a good methodology fixes of production defects need to be verified by testing team before fix moves to production environment]

Ø  All the ‘Deferred’ defects need to be considered for implementation in future versions as version mentioned in JIRA by BA, Testing team will help sending reminders to BA in appropriate versions

Ø  No defect should go unhandled by saying its defect but functionality is same in production or existing in production so NOT FIXED – if it is identified as defect – it needs to be fixed.