A bug does not get fixed by being reported. It moves through a defined lifecycle — from "someone noticed something" to "it is gone, and we have a regression test for it." Understanding the bug lifecycle is essential for every QA engineer because you are the one who shepherds bugs through it.
The standard lifecycle
A typical bug moves through these states:
1. New. A defect has just been logged. Title, description, repro steps, and severity are filled in but not yet validated.
2. Triaged / Confirmed. A QA engineer or tech lead has read the report, reproduced the issue, and confirmed it is genuinely a bug (not user error, not duplicate, not a feature request). Severity and priority are set.
3. Assigned. A developer has been assigned to fix it.
4. In progress / Open. The developer is actively working on the fix.
5. Fixed. The developer has implemented the fix and pushed a commit. The bug moves to QA for verification.
6. Verified / Closed. A QA engineer has run through the original repro steps on a build that includes the fix and confirmed the bug no longer occurs. The bug is closed.
Two important branches exist alongside the happy path:
- Rejected. Triage decides this is not actually a bug. Could be intended behaviour, a duplicate, environment-specific, or out of scope. The reporter should be told why, kindly, with reasoning.
- Reopened. The fix was verified but the bug came back — either because the fix was incomplete or because a new change reintroduced it. Reopened bugs jump back to "Assigned" and the cycle continues.
Why the statuses matter
The status field is more than bookkeeping. It tells the team where the bottleneck is at any given moment:
- A pile of New bugs → triage is overloaded or no one is doing it.
- A pile of Assigned bugs → developers are blocked or the team is over-committed.
- A pile of Fixed bugs awaiting verification → QA capacity is the bottleneck.
- High Reopened rate → fixes are being shipped without enough rigour.
A team that watches these counts in their dashboard will spot process problems weeks before they become release crises.
Common variations
Different teams use different status names and slightly different shapes. Common variants:
- Linear / GitHub Issues. Open, In Progress, In Review, Done. The triage step is implicit.
- Jira's classic flow. Open → In Progress → In Review → Resolved → Closed, with sub-states.
- Banking / regulated industries. May add formal "Awaiting Customer Approval" or "Awaiting Change Board" states.
- Agile teams. Often collapse the lifecycle into the same Kanban board as features, so a bug is just a card with a "type: bug" label.
The exact shape matters less than the principle: every bug should have a clear current state and a clear next person responsible for moving it forward.
Verification: the often-skipped step
The biggest failure point in most teams is verification. A developer marks a bug as "Fixed" and ships it; the bug closes silently because nobody re-tested it; six weeks later it shows up in production. The fix was wrong, or partial, or applied to the wrong branch.
Robust verification looks like this:
- The original reporter (ideally a QA engineer) re-runs the original repro steps on a build that contains the fix.
- They verify the fix works and does not break the surrounding behaviour.
- They add a regression test that covers the case — so the same bug cannot regress.
- Only then do they move the status to Verified / Closed.
Skipping this step is one of the surest ways to lose customer trust over time.
The "won't fix" decision
Not every bug should be fixed. A bug with a tiny user impact, a complex fix, and no recent occurrence may legitimately be "won't fix." This is a deliberate decision, not a quiet one — the bug should be marked as such, the reasoning recorded, and the reporter informed. "Won't fix" is a valid resolution; ignoring is not.
What you should walk away with
The bug lifecycle is the workflow QA owns. Each status has a clear meaning and a clear next step. Triaging promptly, assigning clearly, and verifying rigorously are the three habits that keep the workflow healthy. Up next: the most leverage-heavy skill in the workflow — writing bug reports developers will actually act on.