Software Bug Life Cycle: A Complete Guide

Most teams think they have a bug life cycle because their tracker has statuses. What they usually have is a set of buttons nobody agreed on. The result is familiar: defects sitting in Assigned for three weeks, developers closing their own tickets, and a Fixed column that means "I pushed something" rather than "this is verified gone". The life cycle only pays for itself when every state has one owner and one exit condition. This guide covers every state, the transitions between them, the severity and priority distinction that drives triage, and the metrics worth tracking.

• Every state needs one owner — ambiguity is what makes defects stall.
• Fixed is a claim, Verified is evidence — only a tester moves a defect to Closed.
• Severity and priority are independent — one is technical impact, the other is urgency.
• Rejected, Duplicate and Deferred are valid endings — not every defect becomes a code change.
• Reopen rate is the highest-signal metric — it exposes weak root-cause analysis.

What is the software bug life cycle?

The software bug life cycle (also called the defect life cycle) is the sequence of states a defect moves through from discovery to closure. It exists to answer three questions at any moment: who owns this defect right now, what has to happen for it to move on, and is it actually gone. Without those answers a tracker becomes a graveyard rather than a workflow.

The life cycle is a workflow, not a document. It works when each state has exactly one owner and one exit condition, and it breaks the moment two roles both think the other is holding a defect. That is why the state names matter less than the ownership rules attached to them — you can rename every status in the table below and still have a healthy process, but you cannot have a healthy process where "Assigned" means nobody in particular.

What are the states of the bug life cycle?

Most trackers implement a variation of the states below. Names differ; the stages do not. The critical column is the owner — that is what stops defects stalling.

State	Meaning	Owner	Next states
New	Defect logged, not yet reviewed	Tester	Assigned, Rejected, Duplicate
Assigned	Triaged and given to a developer	Triage / lead	Open, Deferred, Rejected
Open / In Progress	Developer is actively investigating or fixing	Developer	Fixed, Deferred, Rejected
Fixed	Code change complete and merged — a claim, not proof	Developer	Pending Retest
Pending Retest	Awaiting a build containing the fix	Developer / release	Retest
Retest	Tester is verifying the fix in the target build	Tester	Verified, Reopened
Verified	Fix confirmed against the original steps	Tester	Closed
Reopened	Fix failed verification or the defect returned	Tester	Assigned, Open
Closed	Defect resolved and confirmed gone	Tester	Reopened (regression only)
Deferred	Genuine, but not fixed this release	Product owner	Assigned (later release)
Rejected	Not a defect, or not reproducible	Triage / developer	Reopened (with evidence)
Duplicate	Already tracked under another defect	Triage	Closed (links to original)

How does a defect move through the flow?

The happy path is short: a tester finds a reproducible problem and logs it as New. Triage confirms it is real, sets severity and priority, and moves it to Assigned. The developer picks it up (Open), makes the change, and marks it Fixed. Once a build carrying that change reaches the test environment, the defect moves to Retest. The tester re-runs the original reproduction steps, confirms the behaviour is gone, and moves it to Verified, then Closed.

The single most important rule in that sequence is that Fixed and Closed are set by different people. Fixed is the developer's claim that the code change is done. Closed is the tester's evidence that the original symptom no longer occurs in a real build. Collapsing the two — letting developers close their own defects — removes the independent verification that the entire life cycle exists to provide. This is the same separation-of-duties principle that distinguishes quality assurance from quality control: one builds the process, the other inspects the output.

Retesting the specific defect is also not the same as checking you did not break something else. A verified fix still needs regression testing around the change, because the most expensive defects are frequently the ones introduced by a fix rather than the one being fixed.

What do Rejected, Duplicate and Deferred mean?

Not every defect ends in a code change, and that is normal. Three endings close a defect without a fix, and each is abused in a predictable way.

• Rejected — the behaviour is correct, or the report cannot be reproduced. A rejection should always carry a reason. "Works on my machine" is not a reason; an explanation of why the observed behaviour matches the requirement is.
• Duplicate — the same underlying defect is already tracked. Always link to the original rather than deleting, so the duplicate's reproduction steps and environment details stay searchable. Two reports of the same symptom from different environments are often the clue that cracks the root cause.
• Deferred — genuine, but not worth fixing now. This is the most-abused state. Deferred should be an explicit product decision with a review date, not a quiet way to make a number go down. Deferred defects that are never revisited become the backlog nobody reads.

A fourth ending, "Not a Bug", is worth separating from Rejected where your tracker allows it. Rejected often means "we disagree this is broken"; Not a Bug frequently means the requirement itself was unclear. Those are different problems — the second one is a acceptance criteria failure that will keep producing reports until somebody rewrites the requirement.

What is the difference between severity and priority?

Severity is the technical impact on the system; the tester sets it. Priority is the urgency of fixing it relative to everything else; the product owner or triage group sets it. They are independent axes, and the useful cases are the ones where they diverge.

Combination	Example	Typical action
High severity, high priority	Checkout crashes for every user	Stop the line; hotfix
High severity, low priority	Crash in a legacy admin screen used once a year	Schedule; do not block release
Low severity, high priority	Company name misspelt on the homepage	Trivial fix, ship immediately
Low severity, low priority	Minor padding inconsistency on a settings tab	Backlog or deferred

The two off-diagonal rows are exactly why the fields must stay separate. Teams that collapse them into a single "urgency" field lose the ability to say "this is catastrophic but nobody will hit it" — and that sentence is the whole point of risk-based triage.

What makes a good bug report?

A defect that cannot be reproduced cannot be fixed, and it will be rejected regardless of whether it is real. The reproduction steps are the deliverable. A good report contains:

1. A specific title — the symptom and the context, not "login broken".
2. Environment — build number, browser or device, OS, and the exact test environment.
3. Preconditions — the account, role, feature flags and data state required.
4. Numbered steps — the minimal path to reproduce, not the meandering one you took.
5. Expected vs actual result — and the requirement or story that defines "expected".
6. Evidence — screenshot, video, network trace, and the relevant log excerpt with a timestamp.
7. Reproducibility — always, intermittent, or once. Say so honestly.

That last field matters more than teams expect. An intermittent defect logged as if it were deterministic will be rejected on the first failed reproduction attempt, and the underlying race condition survives to production. Say "3 of 10 attempts" when that is the truth — that number is itself a diagnostic clue, and it is often the first hint of the timing and concurrency problems that surface under stress testing.

How does defect triage work?

Triage is the recurring decision meeting that converts New defects into committed work. A working triage has a fixed cadence (daily during a release, weekly otherwise), a fixed quorum (product, development, test), and a strict scope: decide, do not debug. The moment triage starts diagnosing a defect it stops being triage and becomes an unplanned engineering session that blocks every other item in the queue.

For each defect, triage answers four questions: is it real, is it a duplicate, what are its severity and priority, and who owns it next. Anything requiring investigation gets timeboxed to a named person and returns to the next session. Teams running structured QA consulting engagements usually find triage discipline is the cheapest single improvement available — it costs nothing and it unblocks everything downstream.

Which bug life cycle metrics actually matter?

Defect counts are close to meaningless in isolation, because they measure how hard you looked as much as how broken the software is. The metrics below measure the health of the process instead.

• Reopen rate — the share of fixes that fail verification. The highest-signal metric on this list. A rising reopen rate means fixes are addressing symptoms rather than causes, or that the test environment does not represent reality.
• Defect leakage — defects found in production that should have been caught earlier. This is the honest measure of whether your test coverage matches real usage.
• Defect age by state — how long defects sit in each state. Long dwell time in Assigned means triage is assigning work nobody has capacity for.
• Defect density — defects per module or per unit of change. Useful for finding the components that deserve a rewrite rather than another patch.
• Rejection rate — a high rate usually indicates unclear requirements or weak reproduction steps, not incompetent testers.

Treat all of these as trends, never as targets. The moment a defect count becomes a performance target, it stops measuring quality and starts measuring how willing people are to log defects — and you lose the data that made the metric worth having.

How does the bug life cycle map to Jira or Azure DevOps?

Neither tool ships the canonical life cycle out of the box, and both let you build it. In Jira, the default Bug workflow is deliberately minimal — roughly To Do, In Progress, Done — which is why teams that adopt it unchanged end up with a Done column that conflates Fixed and Verified. Adding explicit Retest and Verified statuses, plus separate Severity and Priority fields (Jira ships Priority but not Severity), reproduces the model in this guide.

Azure DevOps ships closer to it: its Bug work item has New, Active, Resolved and Closed, where Resolved maps to Fixed and Closed maps to Verified, along with separate Severity and Priority fields. The gap in both tools is the same one: enforcing that the person who resolves a defect is not the person who closes it. That is a workflow rule and a team agreement, not a feature you can install.

Whichever tool you use, keep the status list as short as the ownership rules allow. Every extra state is another place a defect can sit while two people each believe the other is holding it.

What are the common bug life cycle anti-patterns?

• Developers closing their own defects — removes verification entirely.
• Fixed used as Closed — a merged pull request is not a verified fix.
• Deferred as a dumping ground — deferrals with no review date are hidden debt.
• Severity set by whoever shouts loudest — severity is technical impact, not volume.
• No environment or build number — guarantees an unreproducible, rejected defect.
• Triage that debugs — turns a 20-minute decision meeting into a 2-hour blocker.
• Bulk-closing stale defects — makes the number look good and destroys the evidence.
• Untested error paths — the states that produce the worst production defects are frequently the ones nobody wrote a case for. See error handling in software testing.

How Appsierra helps

A defect workflow only works if somebody owns it. Appsierra's expert-supervised QA pods run the whole loop — reproduction, triage discipline, verification and regression around each fix — as part of our quality assurance services, rather than handing you a dashboard and leaving the process to drift. Senior engineers review the work, so Fixed means fixed and Closed means verified.

If your reopen rate is climbing or triage has quietly become a two-hour debugging meeting, that is usually a process problem rather than a people problem, and it is fixable. Our QA consulting engagements start by measuring where defects actually stall before changing anything. You can also size the opportunity yourself with the QA ROI calculator.

Appsierra is ISO 9001 and ISO 27001 certified and CMMI-aligned, and every engagement can start as a risk-free paid pilot tied to a metric you choose — reopen rate and escaped defects are common ones. If you would rather talk it through first, book a free 30-minute call and a senior engineer will give you an honest read on where your defect flow is losing time.

Frequently asked questions