1.5The Defect Lifecycle

A well-defined defect lifecycle ensures bugs are tracked from discovery to resolution. Every bug moves through a series of statuses, each with a clear owner and clear expectations.

New --> Open --> In Progress --> Fixed --> In Verification --> Closed
                   |                          |
                Deferred                   Reopened --> In Progress
                   |
             Won't Fix / Duplicate

Statuses Explained

Status	Who Owns It	What Happens
New	QA (creator)	Bug is reported with all required information
Open	Team lead / Triage	Bug is reviewed, prioritized, and assigned
In Progress	Developer	Developer is actively working on the fix
Fixed	Developer then QA	Fix is committed, PR merged. Moves to QA for verification
In Verification	QA	QA verifies the fix in the target environment
Closed	QA	Fix verified successfully
Reopened	QA then Developer	Fix did not resolve the issue or introduced a new problem
Deferred	Team lead	Won't be fixed this release; moved to future sprint
Won't Fix	Team lead + PO	Accepted as-is; not worth the effort to fix
Duplicate	QA / Team lead	Same bug already reported; link to the original

Transition Rules

Not every transition should be allowed. A well-configured Jira workflow enforces rules:

• Only QA can move a ticket to "In Verification" (prevents developers from verifying their own fixes)
• Only QA can close a ticket (ensures independent verification)
• Reopened tickets must include a comment explaining why the fix was insufficient
• Deferred tickets require a target sprint or version