How the Defect Life Cycle Breaks at 3 Transitions

Draw the diagram and everyone nods: New leads to Assigned leads to Open leads to Fixed leads to Retest leads to Verified leads to Closed. Seven boxes, seven arrows, no disagreement. Then someone files a defect the developer can't reproduce on the first try, someone reopens a bug that was closed two sprints ago, or someone quietly moves a defect to deferred and nobody ever revisits it. None of those three things live on the seven-box diagram, and all three are where a real bug triage process actually breaks down.

This is for the QA engineer or SDET who needs the vocabulary cold: for an interview, a study guide, an onboarding doc, or an auditor asking why a ticket sat in cannot reproduce for six months. It is not for the QA lead deciding how much of a sprint to spend on triage policy, that is a strategy document, not a definition to memorize, and it is not for the team asking whether their AI-written tests are theater rather than proof. Just the states, all eleven of them, and the three transitions between them that actually cause arguments.

The full defect life cycle: all eleven states

Eleven states cover a defect's actual life, not the seven most diagrams draw.

State	What it means	On most diagrams?
New	The report exists; nobody has looked yet	Yes
Assigned	Someone owns triaging it	Yes
Open	The assignee is actively working on a fix	Yes
Fixed	A fix is written, waiting on confirmation	Yes
Retest	QA runs the case that originally failed	Yes
Verified	QA confirms the failure no longer reproduces	Yes
Closed	The record is done, no more action expected	Yes
Deferred	Won't be fixed now; owner and date set	No
Duplicate	Same underlying issue as one already tracked	No
Cannot Reproduce	Assignee tried the steps; failure didn't happen	No
Reopened	A previously resolved defect came back	No

That's the seven-box tour, and it's a fine skeleton for the stages of a bug life cycle. It is also not a policy, because it says nothing about the four states that generate nearly every real disagreement on this list: Deferred, Duplicate, Cannot Reproduce, and Reopened. Bugzilla's own docs make the same point from the tool side: the life cycle of a bug is meant to be customized to match the needs of your organization, so the state set is a decision your team makes, not one the tracker hands you (Bugzilla documentation). One of those four needs a definition before it does any work: "Resolved" is the umbrella most trackers use for any state where a ticket stopped being active work, whether that was Fixed, Verified, Closed, or closed as a Duplicate, and it's the state Reopened actually reopens from.

Every one of the four dropped states is a state your bug triage process has to have an opinion about, or it doesn't have a bug triage process, it has a diagram. Our triage playbook for a quality crisis piece covers the meeting cadence and playbook side of that process; what follows here is the transition policy underneath it, not another playbook.

Three transitions the bug triage process has to own

Three transitions generate nearly every disagreement in a live tracker, and each needs the same three things settled: an evidence bar, an owner, and a time limit.

Watch the three branches cycle: the workflow remains reviewable only when evidence, ownership, and a decision deadline move with the state.

New to Cannot Reproduce

What cannot reproduce actually means is narrower than "I didn't see it": the assignee ran the exact steps, on a stated build and environment, and the failure did not occur. The evidence bar requires the steps attempted, the environment and build tested, and a log excerpt or a note that none exists. A report missing steps, environment, or expected-versus-actual isn't a cannot reproduce candidate, it's a rewrite candidate; our bug report template piece owns what a complete report contains.

A large share of what lands in cannot reproduce is test flakiness, not a bad report: steps followed, environment matched, and the failure still didn't show up on that run. Google's own engineering blog measured this on its CI suite specifically: about 84% of the pass-to-fail transitions it observed involved a flaky test, with a continual baseline near 1.5% of all test runs reporting a flaky result (Google Testing Blog). That's a measurement of automated CI test transitions, not of human-filed cannot-reproduce tickets, but it's evidence the underlying phenomenon is large everywhere it's actually been measured. Our flaky tests piece covers why, and our guide to debugging flaky tests covers what to do next. The assignee proposes the transition; it stays provisional until the reporter has a defined window, a handful of business days is a reasonable default, to supply what's missing before the ticket closes as won't-fix or reopens with better evidence.

Resolved to Reopened

Who can reopen a defect is narrower than "anyone who disagrees with the fix." The evidence bar is the same repro steps failing again, not a new symptom on the same feature. The owner is the original reporter or the QA engineer who verified the fix, not an arbitrary team member relitigating the call. The time limit ties the reopen window to the release that shipped the fix; anything after that gets filed fresh, referencing the original ticket instead of reopening it.

New to Deferred

Deferred versus closed is where a policy differs from a shrug. A legitimate deferral has a named owner who isn't the assignee, a linked milestone the defect is deferred to, and a review date it actually gets revisited. Missing any of those three, it's a silent close with a different label: nobody revisits it, and the next person to hit the same defect files a new ticket instead of reopening the old one.

Transition	Evidence bar	Owner	Time limit
New to Cannot Reproduce	Steps tried, environment, log or its absence	Assignee proposes it	Reporter responds in days, not weeks
Resolved to Reopened	Same repro steps, re-failing	Reporter or verifying QA	Tied to the release that shipped the fix
New to Deferred	Named milestone and review date	Owner with authority, not the assignee	Reviewed every sprint or release

Severity and priority get assigned in this same flow, usually at New or Assigned; our severity versus priority piece owns that pair and where they disagree.

How Autonoma reduces the cannot-reproduce bucket

Look back at the evidence bar for the first transition: steps tried, environment, and a log or the explicit absence of one. That evidence bar exists because reproducing a defect used to be expensive to prove either way, so the process substituted argument for evidence. The reporter says it happened, the assignee says it didn't, and the ticket sits in Cannot Reproduce until someone with more patience than the other side wins.

That's the plain-English version of what changes with our agents at Autonoma, and it's an architecture point, not a numbers claim. Autonoma reads a codebase to work out what a flow is actually supposed to do, then verifies it by driving the real, running application in a live preview environment rather than asking a person to click through it by hand. When a run fails, the failure carries its own trace and its own environment: the build, the steps attempted, and what the application actually did, attached automatically instead of reconstructed from memory two days later when someone finally has time to look.

Put that next to the evidence bar table above: evidence bar, owner, time limit exist as a policy because attaching real evidence to a claim used to be hard enough that teams needed a rule for adjudicating disagreement instead. An agent that already drove the failing run has the evidence-bar column filled in before a person opens the ticket. It isn't reconstructing steps from a report written under deadline pressure two days after the fact; it has the sequence it actually executed, the state the application was actually in, and the output it actually produced, because it just ran it. The owner and the time limit columns don't change at all. What changes is that the assignee opening a Cannot Reproduce ticket is arguing from a trace instead of from a memory of trying it once, on whatever branch happened to be checked out.

That doesn't empty the cannot reproduce bucket. A defect that only appears on one customer's specific device, or under a load condition no test environment replicates, is still genuinely environment-specific, and still needs a human to chase it down. What it removes is the argument over whether the first attempt happened at all and what the assignee's environment looked like when they tried it, which is most of what fills that bucket today. It doesn't decide whether a defect gets deferred, it doesn't set severity or priority, and it doesn't decide who's allowed to reopen something; it changes what evidence shows up at the New to Cannot Reproduce transition before anyone has to argue about it.

The same pipeline also answers a question a person usually has to guess at from a trace anyway. When a run fails, a review step classifies the result before anyone opens the ticket: a real product bug, an error in the agent's own run, or a mismatch between what the test expected and what the flow now actually does. That's the same three-way split a human assignee makes when they stare at a failed run and ask whether the app broke, whether they made a mistake reproducing it, or whether the test itself is stale, except it happens before the ticket lands in anyone's queue instead of after a day of back and forth in the comments.

The same technique, applied to your product

You just agreed a state machine for your own defect records: eleven states, three transitions worth fighting over, an evidence bar for each. The same discipline runs in the other direction too, into the state machines inside the product you ship, not just the one your tracker runs. State transition testing is the technique for that side: name every state a flow can be in, name every event that requests a move, and test the refusals as carefully as the happy path. We walked that exercise on an order lifecycle in that piece; the defect life cycle above is the same shape of problem, run on the process instead of the product.

Seven states make a fine diagram. Eleven states, with a policy for the three transitions that actually cause arguments, make a bug triage process a team can point to instead of relitigating in a Slack thread every time. Write down who owns each of those three moves, what evidence they require, and how long a ticket can sit before the clock forces a decision, and most of the arguments a live tracker generates stop being arguments. None of that requires new tooling to start: a shared doc naming the owner and the time limit for each of the three transitions turns Monday's argument into a two-minute lookup instead of a Slack thread. The state machine was already running whether or not anyone had written it down; the only open question was whether the three contested moves got a rule before the next dispute or after it. Autonoma doesn't settle any of those three calls for you, whether to defer, whether to reopen, whether the report was bad; what changes is how much evidence shows up before anyone has to argue at all.

Frequently Asked Questions