Bug Life Cycle
Finding a bug — whether through a scripted test case, a regression run, or an exploratory session — is only the beginning. From the moment a tester spots something wrong until it's confirmed fixed (or formally decided it won't be fixed), that bug moves through a defined sequence of states called the bug life cycle (also called the defect life cycle). Every serious QA team tracks bugs this way in a tool like Jira, Azure DevOps, or Bugzilla, precisely so that nothing reported ever silently gets forgotten.
The Main Path: New to Closed
| State | What it means | Who's responsible |
|---|---|---|
| New | A tester has just logged the bug. It hasn't been reviewed by anyone else yet. | Tester (reports it) |
| Assigned | A test lead or QA manager has reviewed the bug, confirmed it looks valid, and assigned it to a specific developer. | Test lead / QA manager (triages and assigns) |
| Open / In Progress | The assigned developer has picked it up and is actively investigating or fixing it. | Developer |
| Fixed | The developer believes the code change resolves the issue and has checked it into a build. | Developer |
| Retest | The bug sits waiting for a tester to verify the fix against the new build. | Tester (picks it up to retest) |
| Verified / Closed | The tester confirmed the fix works as expected and the bug is formally closed. | Tester (verifies and closes) |
The State Flow, Described
New → Assigned → Open/In Progress → Fixed → Retest → Verified/Closed is the "everything went smoothly" path. But real bug tracking has to account for cases where it doesn't go smoothly — those are the alternate paths below, and they can branch off at almost any point in the main flow.
Alternate Paths
| Alternate State | When it happens | Who triggers it |
|---|---|---|
| Reopened | A tester retested a "Fixed" bug and found it still fails, or fails in a slightly different way. It goes back to Open/In Progress instead of Closed. | Tester |
| Rejected | The lead or developer decides this isn't actually a bug — perhaps it's working as designed, or the tester misunderstood the requirement. | Test lead or developer |
| Deferred | The bug is valid, but the team decides to postpone fixing it to a later release — usually because it's low severity/priority and the release deadline is close. | Test lead / product owner |
| Duplicate | The same underlying problem was already logged as a different bug ID. This one is closed and linked to the original. | Test lead (during triage) or developer |
Worked Example: Tracing a RecipeBox Bug
Bug: "Prep Time field accepts negative numbers on the Add Recipe screen."
- New — A tester finds that entering
-5into Prep Time saves the recipe without any validation error, and logs it. - Assigned — The QA lead reviews it during the daily triage meeting, confirms it's a real, valid issue, and assigns it to the developer who owns the Add Recipe form.
- Open / In Progress — The developer starts adding a validation rule (minimum value 1) to the Prep Time field.
- Fixed — The developer checks in the validation change and marks the bug Fixed, noting the build number it will ship in.
- Retest — The tester picks up the new build and re-enters
-5; this time it's correctly rejected with a clear error message. - Verified / Closed — The tester also checks the boundary (
0and1) and the Edit Recipe screen sharing the same field, confirms everything behaves correctly, and closes the bug.
Now suppose instead that step 5's retest showed the field still accepted -5 because
the developer only fixed Add Recipe and forgot Edit Recipe shares the same form component. The
tester would move the bug to Reopened instead of closing it, with a note
explaining exactly which screen still fails — sending it back to Open/In Progress for another
attempt.