Bug Life Cycle: The States a Defect Moves Through

TL;DR

• The bug life cycle is the sequence of states a defect occupies from report to closure, with one named owner and an explicit exit condition at each step.
• Seven core states, three branches, and one loop. Reopened is the state carrying diagnostic information, since a defect cycling three times points at report quality rather than developer skill.
• Each state needs an age limit. A queue of defects sitting in New for two weeks identifies triage as the bottleneck.
• Autosana links each failure to an issue record with device-level video, so Retest produces evidence rather than an assertion.

A defect is marked Fixed on Tuesday, Reopened on Thursday, Fixed again on Friday, and Reopened the following Monday. Three cycles, two engineers, and the underlying cause was a missing device model in the original report.

The bug life cycle makes that visible. Each state has an owner and an exit condition, so a defect looping between two states turns the loop itself into the finding.

This guide covers the states, who owns each, how long a defect should sit in one, the branches ending a defect without a code change, and what a device matrix does to Retest.

What Is the Bug Life Cycle?

The bug life cycle, also called the defect life cycle, is the defined set of states a defect passes through from discovery to closure. The defect management is a core test activity, and ISO/IEC/IEEE 29119-3 specifies the incident report content travelling with it.

Two properties make a bug life cycle useful rather than ceremonial. Every state has exactly one owner, so at any moment one named person is responsible. Every transition has a condition, so moving a defect forward requires something to have happened.

Where either property is missing, the workflow becomes labels people apply inconsistently, and the status field loses its predictive value.

What Are the Seven States in the Bug Life Cycle?

What Happens in the New State?

The defect has been reported and awaits triage. A queue of New defects older than a few days identifies triage as the bottleneck rather than development, which is a staffing decision rather than an engineering one.

What Happens in the Assigned State?

Triage accepted the defect and allocated it. Severity and priority get set here, by the people who own each.

Defects assigned to a team rather than a person tend to sit, since shared ownership leaves the pickup to chance.

What Happens in the Open State?

The assigned developer is investigating or fixing. Exit happens when a fix is written, or the defect moves to one of the branches below.

Age limits here should scale with severity rather than being uniform. A critical defect sitting in Open for a week is a process failure; a trivial one doing the same is normal.

What Does Fixed Actually Mean?

A code change was made and merged. Ownership transfers back to QA.

The rule that matters: Fixed is a claim by development rather than a verified outcome. Treating it as closure is how defects reach production marked resolved.

Who Owns the Retest State?

QA re-runs the original failing case against a build containing the fix. This state carries the most leverage in the whole cycle, covered in depth below.

What Does Verified Require as Evidence?

The retest passed on every target configuration. A verified defect carrying no recorded run against a named build is an assertion rather than a verification.

When Should a Defect Be Closed?

After Verified, always. Workflows permitting a direct jump from Fixed to Closed skip the only step checking the fix worked.

Who Is Allowed to Move a Defect Between States?

Transition permissions matter as much as the states themselves, since an unrestricted workflow produces defects moving backwards for convenience.

Three rules cover most situations.

Development moves a defect into Fixed and no further. A developer closing their own defect removes the verification step by definition.

QA moves a defect into Verified and Closed. QA also owns the Reopened transition, since reopening is a verification outcome.

The product owner changes priority at any time, while severity stays with whoever assessed it. Severity describes the system and priority describes the business, so they move on different authority.

Write these into the tool rather than the wiki. A workflow permitting any transition will eventually see every transition.

What Are the Rejected, Duplicate, and Deferred States?

Three outcomes end a defect without a code change, and each needs its own state rather than folding into Closed.

Rejected. Behaviour matches the requirement, so this is a requirement gap or a misunderstanding. Record the reasoning, since the same report will arrive again.

Duplicate. Another record covers it. Link the two rather than deleting one, since the duplicate often carries reproduction detail the original lacks. Merge the evidence before closing.

Deferred. The defect is real and the business accepts it for now. This needs a review date attached, otherwise Deferred becomes a graveyard that escapes audit.

Keeping these distinct matters for metrics. A Rejected rate climbing past a few percent points at requirements written loosely rather than at QA raising noise.

Why Does a Defect Reopen Repeatedly?

Reopened carries diagnostic information. One reopen is normal. Three or more means something structural, and the cause is usually one of four.

The original report was incomplete. A missing device model, build number, or data value means the developer fixed what they could reproduce rather than what was reported. This is the most common cause by a wide margin.

The retest ran on a different configuration than the report. Fixed on a Pixel, reported on a Galaxy, retested on whichever device was free.

A symptom was addressed rather than the cause. The visible failure stopped while the underlying condition remained, so it resurfaces through a different path.

The defect is intermittent and the retest caught a passing run. Absent a recorded frequency, one passing execution reads as proof.

Track reopen counts per defect and review anything past two. The cause is almost always upstream, in how reports and retests are evidenced. Martin Fowler's test pyramid applies here too: a defect caught at the unit layer completes the whole bug life cycle in minutes, while one found in production takes days.

Which Bug Life Cycle Metrics Are Worth Tracking?

The cycle itself produces measurements that name where the process leaks.

That last row exposes a common gap. Where critical and trivial defects show similar cycle times, severity is being recorded rather than acted on, and the field has become decoration.

How Does a Device Matrix Change the Retest Step?

Retest is where mobile changes the bug life cycle most.

A defect reported on one device and retested on that device alone proves the fix works on that device. Where the defect class is layout, gesture, or vendor-specific behaviour, that proves little about the rest of the matrix.

Three rules keep Retest honest.

Retest on the reporting configuration first, using the same build, OS version, and data. Anything else is a different test.

Extend to at least one other manufacturer and one other OS version. This is where fix-one-break-another surfaces, and it costs minutes.

Record per configuration rather than as a single pass. A fix verified on four devices and failing on the fifth is a failure, and flattening hides it.

Testing a mobile app at this level needs the matrix to be cheap, otherwise rules two and three get skipped under deadline. Regression testing follows Verified, confirming the fix left surrounding behaviour intact, while smoke tests gate whether the build was worth retesting at all. For defects reported from production, real device testing is usually what reproduces them.

For defects found during UAT, the cycle gains an extra approval: business sign-off that the fix meets the original criterion rather than merely stopping the error.

How Autosana Fits

We make Retest and Verified carry evidence instead of assertions.

Every run records video and step-level results per device. A retest produces a replay showing the exact step on the exact configuration, attached to the issue record, so Verified means something checkable.

Our flows run across real devices in parallel, making retest on a second manufacturer and a second OS version the default rather than an extra task requiring justification.

Suites map to the stage in the bug life cycle: a targeted suite for retest, a broader one for the regression pass following Verified.

Notifications move the defect between owners at each transition, and team settings keep the single-named-owner property intact rather than assigning to a group.

Conclusion

Pull your defects from the last quarter and count how many reopened more than twice.

For each, check whether the original report named a device model and a build number. The correlation is usually strong enough to be the whole explanation, which points the fix at report quality rather than at the engineers doing the fixing.

Then compare cycle time for critical defects against trivial ones. Where the two look similar, severity is decoration rather than a routing decision.

FAQ

What is the bug life cycle?

The bug life cycle is the defined set of states a defect passes through from report to closure, with a single named owner and an explicit exit condition at each state. It is also called the defect life cycle.

What are the states in a bug life cycle?

New, Assigned, Open, Fixed, Retest, Verified, and Closed, plus the branch states Rejected, Duplicate, and Deferred, and the loop state Reopened.

Who owns each state?

The reporter owns New until triage. Triage owns Assigned. The developer owns Open and Fixed. QA owns Retest and Verified. Closed belongs to the archive.

Who should be allowed to close a defect?

QA, after Verified. A developer closing their own defect removes the verification step by definition, so development should move a defect into Fixed and no further.

What does it mean when a defect is reopened repeatedly?

Usually the original report lacked a device model, build number, or data value, so a different reproduction got fixed. Other causes are retesting on the wrong configuration, addressing a symptom, or an intermittent defect passing once.

Why should Fixed and Verified be separate states?

Fixed is a claim by development that a change was merged. Verified is a confirmed result from QA re-running the failing case. Collapsing them removes the only check that the fix worked.

Which bug life cycle metrics matter?

Age in New identifies triage capacity. Time from Fixed to Verified identifies retest capacity. Reopen rate measures evidence quality. Cycle time by severity shows whether severity changes urgency at all.

How does a device matrix change the retest step?

Retest on the reporting configuration first, then extend to another manufacturer and OS version. Record per configuration, since a fix passing on four devices and failing on a fifth is a failure.