Bug Life Cycle in Software Testing: States and Who Moves Them

The bug life cycle in software testing, also called the defect life cycle, is the path a bug takes from report to close. The usual states are New, Assigned, Open, Fixed, Retest, Verified and Closed, with five side exits: Reopened when a retest fails, and Deferred, Rejected and Duplicate when the bug will not be fixed now or at all. Each state has an owner: the reporter files it, triage accepts or turns it away, a developer fixes it, a tester confirms the fix, and the person who orders the work decides what waits. Most teams can run the same cycle on four lanes plus one field that records how each bug ended. The details, the four-lane version and the rules for reopening are below.

The ISTQB glossary, the standard vocabulary for testers, calls this defect management↗ (opens in a new tab): the process of recognizing, recording, classifying, investigating, fixing and disposing of defects. The life cycle is that process drawn as states, so everyone can see where each bug is and who has it.

The standard states, and who moves each one

STATE       MEANS                                   MOVED HERE BY
New         Reported, not yet looked at             Reporter (tester, user, support)
Assigned    Accepted as a real bug; has an owner    Triage lead
Open        A developer is working on it            Developer
Fixed       Change made and merged                  Developer
Retest      Fix is in a build testers can reach     Developer or release owner
Verified    Tester confirmed the bug is gone        Tester
Closed      Done; nothing more to do                Tester or triage lead

Side exits
Reopened    Retest failed, or it came back          Tester (or anyone, with evidence)
Deferred    Real, but not fixing it now             Person who orders the work
Rejected    Not a bug: works as designed            Triage lead
Duplicate   Already reported elsewhere              Triage lead, pointing at the original

• New to Assigned is triage. Someone who knows the product reads the report, tries to reproduce it, sets severity and gives it an owner. A bug nobody triages stays New forever, and the reporter learns that reporting is pointless.
• Assigned to Open to Fixed belongs to the developer. Open says “I am on it”, which stops two people fixing the same thing.
• Fixed to Retest is a hand-off, and often the forgotten one. A fix that is merged but not in any build a tester can reach cannot be verified.
• Retest to Verified or Reopened belongs to the tester, and it is not the developer’s call. ISTQB calls this step confirmation testing↗ (opens in a new tab): testing performed after fixing a defect to confirm that the failure it caused does not reoccur.
• Deferred is a priority decision, so it belongs to whoever orders the team’s work, with a reason written down. How that decision is made is covered in bug severity vs priority.
• Rejected and Duplicate are triage decisions and need a reason or a link. “Works as designed” with no explanation starts an argument; “works as designed, see the spec for export limits” ends one.

Real trackers differ, and that is fine

No two tools use exactly this list. Bugzilla, one of the oldest open-source trackers, documents its bug status workflow↗ (opens in a new tab) as fully customizable: administrators define the statuses and resolutions and tick which transitions are allowed. Only one status, UNCONFIRMED, can never be renamed or deleted, and only two resolutions, DUPLICATE and FIXED, are fixed in place. Everything else is local choice.

What matters more than the names is how the tool treats a bug that cannot yet be acted on. Mozilla’s triage guidelines↗ (opens in a new tab) for Firefox say that when an unconfirmed bug has no steps to reproduce, the triager asks the reporter for them, is not obliged to wait forever, and can resolve the bug as INCOMPLETE if the request goes unanswered. The same guidelines expect every new bug to be triaged, or under active investigation, within a week of being filed. Those two rules, ask once and close with a reason, and never leave New unread, do more for a bug tracker than any number of extra states.

Where the bug is vs how it ended

Look closely at the standard list and it mixes two questions. New, Open, Fixed, Retest and Verified say where the bug is. Rejected, Duplicate, Deferred and Closed say how it ended, or that it stopped. Bugzilla separates these into a status and a resolution, and that split is what lets a small team shrink the cycle without losing information.

• Where it is: waiting, next, being worked on, finished. Four places cover it.
• How it ended: fixed and delivered, or closed without a fix for a stated reason. That is a field on a finished bug, not another column.
• Everything else, such as who reported it, severity, which build the fix is in and whether it has been retested, lives in the bug’s own record, where it does not need a lane of its own.

A simple four-lane version

LANE          STANDARD STATES IT COVERS          WHO MOVES A BUG IN
To Do         New, Assigned, Deferred             Reporter files; triage sets priority
Next Up       Assigned and ready to start         Person who orders the work
In Progress   Open, Fixed, Retest                 Developer
Completed     Verified, Closed, Rejected,         Tester confirms, or triage closes
              Duplicate                           with a reason

On Completed, record how it ended:
  Completed         fixed and verified
  Won't fix         real, but a decision not to fix it
  Duplicate         link the original
  Cannot reproduce  after asking the reporter for steps
  Obsolete          the feature or code is gone

Retest sits inside In Progress on purpose: a bug is not finished until someone other than the author has checked it, so it stays in progress until then. If your team wants retest visible at a glance, record it on the bug rather than adding a fifth lane; a test status of Not tested, Failed or Tested on each bug says the same thing and cannot drift out of step with the lane.

Reopening: when and how

• Reopen when the retest fails. Say what was tested, on which build, and what happened. “Still broken” is not enough for the developer to act on.
• Reopen when the same bug comes back soon after closing, with the same steps and symptom. The history of the first fix is useful to whoever looks next.
• File a new bug, linked to the old one, when the symptom is similar but the cause or steps differ, or when the old one closed long ago. Reopening a bug from last year hides the fact that something regressed, and that is its own finding.
• Reopen a Duplicate or Cannot reproduce when new evidence arrives, such as steps that do reproduce it, and say what changed.
• A bug that has been reopened more than once deserves a regression test before it is closed again. The regression testing checklist shows how fixed bugs become permanent tests.

Duplicates are the most common false start, and marking one properly saves the next person a search. GitHub, for example, lets you mark an issue as a duplicate↗ (opens in a new tab) by commenting “Duplicate of” followed by the original issue number, which links the two in the timeline.

The bug life cycle on a fenbs board

fenbs runs the four-lane version as it stands. Every task is a feature, an enhancement or a bug, and a bug gets a BUG- ref such as BUG-118. The lanes are To Do, Next Up, In Progress and Completed, and moving between lanes is its own permission. Give testers and customers the suggested Reporter role: they can add bugs, edit the ones they added and comment, but cannot move bugs between lanes, so the life cycle stays with the people who triage and fix. Priority runs 1 to 10, 1 the most urgent.

A bug in Completed records how it ended, chosen in the task editor: Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete. Only Completed counts as delivered, so closing a pile of stale bugs as Obsolete does not flatter the board’s figures. The Testing section records the retest, Not tested, Tested, Partly tested or Failed, with notes on what was checked, and the board filters for Completed tasks that nobody has tested. Moving a task out of Completed clears how it ended, which is what reopening should do. When an AI assistant files a bug over MCP, fenbs first checks open tasks and those finished in the last 14 days; if one looks like the same thing, it returns the match instead of a second copy, so the assistant can comment, reopen the finished one, or file a new bug linked to it. Every move, by a person or an assistant, is recorded in History with who made it.