Learner can order the defect lifecycle statuses and write a complete, well-structured bug report from a described scenario.
The defect lifecycle
The defect lifecycle
Every defect moves through a series of statuses from discovery to closure. Understanding these statuses helps testers and developers collaborate without confusion.
The main flow: New (tester logs the defect) → Open (team acknowledges it is valid) → Assigned / In Progress (a developer is working on it) → Fixed / Resolved (developer marks it done) → Retest (QA verifies the fix in the same environment) → Closed (fix confirmed, defect archived).
There are three important branch statuses. Reopened: QA retested and the fix did not work — the defect goes back to Open/Assigned. Rejected: the team decides the reported behaviour is actually correct by design, or the report is invalid. Duplicate: the same defect was already reported under another ticket — this report is closed pointing to the original.
Key trigger points to remember: only QA should move a defect to Closed (after successful retest, not the developer); a developer must not close their own defect. If a fix is deployed but QA finds the issue still exists, the status becomes Reopened, not a new defect — this preserves the history.
Lesson notes
The defect lifecycle
Every defect moves through a series of statuses from discovery to closure. Understanding these statuses helps testers and developers collaborate without confusion.
The main flow: New (tester logs the defect) → Open (team acknowledges it is valid) → Assigned / In Progress (a developer is working on it) → Fixed / Resolved (developer marks it done) → Retest (QA verifies the fix in the same environment) → Closed (fix confirmed, defect archived).
There are three important branch statuses. Reopened: QA retested and the fix did not work — the defect goes back to Open/Assigned. Rejected: the team decides the reported behaviour is actually correct by design, or the report is invalid. Duplicate: the same defect was already reported under another ticket — this report is closed pointing to the original.
Key trigger points to remember: only QA should move a defect to Closed (after successful retest, not the developer); a developer must not close their own defect. If a fix is deployed but QA finds the issue still exists, the status becomes Reopened, not a new defect — this preserves the history.