Defect Life Cycle Explained: Bug Status Workflow

The bug was fixed, but nobody could prove where

A payment defect moved from Open to Done on Tuesday. On Thursday the tester found the same failure in staging, the developer said the fix was only deployed to an integration environment, and the release manager assumed Done meant verified. The status had compressed three different facts into one word.

A defect life cycle should prevent that ambiguity. It is an agreement about evidence, ownership, and permitted transitions. The exact labels matter less than the questions each transition answers:

• Has the report been reproduced and accepted as actionable?
• Who owns the next action?
• Which code change is supposed to resolve it?
• Where is that change available for verification?
• What evidence supports closure or a decision not to fix?

Design the workflow around the delivery system. A team releasing a web service daily needs different waiting states from a medical-device team maintaining released versions. Copying twenty statuses from another organization usually creates queues nobody manages.

Define states by entry and departure rules

Start with the smallest state model that exposes handoffs. Seven core states are often enough, with resolution reasons stored separately.

Teams may call these states Accepted, Resolved, QA Ready, or Verified. Publish one-line definitions inside the tracking system so “Resolved” cannot mean both “developer wrote code” and “tester proved the behavior.”

Keep outcome separate from workflow position. Duplicate, Works as designed, Cannot reproduce, Deferred, and Won’t fix are resolution reasons. They explain why active work ended. Turning each reason into a long-lived queue makes reporting harder and hides who must act.

Make a new report triage-ready

A New defect should arrive with enough evidence for another person to make progress without interviewing the reporter. Include the observed behavior, expected behavior, minimal reproduction path, environment and build, data conditions, frequency, and supporting logs or images. Remove secrets and personal data from attachments.

For an intermittent checkout timeout, “sometimes payment fails” is not actionable. A stronger report says:

• build: storefront 8.14.2-rc3
• environment: staging-eu, Chrome, authenticated retail account
• setup: saved card token, cart total above 500 EUR
• observation: confirmation remains pending; order service returns gateway timeout
• frequency: 3 of 10 attempts between 10:10 and 10:18 UTC
• correlation IDs: three sanitized request identifiers
• expected: a completed order or a recoverable decline, with no duplicate order

The report should also state customer impact without pretending to know the root cause. “Buyer cannot tell whether the order was placed and may retry” is observable impact. “Database race condition” is speculation until engineering confirms it.

If the required evidence cannot be captured, record what is missing and who will obtain it. Leaving a weak report in New for weeks is not investigation.

Triage validity, severity, and priority separately

Triage decides whether the defect is actionable and what the organization will do next. It is not a contest over labels.

Validity asks whether the observed behavior conflicts with an agreed expectation. Severity describes the technical or user impact if the behavior occurs. Priority describes the order and urgency of action given release timing, exposure, strategic commitments, and available mitigations.

A spelling error on a campaign landing page may have low functional severity but immediate priority before a launch. Rare data corruption may have critical severity even when a safe feature flag allows the team to postpone the permanent fix. Do not force priority to mirror severity.

A focused triage meeting answers:

1. Can we reproduce or otherwise trust the evidence?
2. Which requirement, design, or operational expectation applies?
3. Who and what are affected?
4. Is there a workaround, rollback, or containment action?
5. Which release or service objective is at risk?
6. Who owns investigation, and when is the next decision?

Record disagreements as facts. If product accepts behavior that QA considered defective, link the clarified requirement and close with the relevant resolution. Do not silently relabel the defect as invalid.

Carry fix identity through the handoff

The developer’s completion artifact is not “fixed locally.” It should identify the suspected cause, change reference, affected versions, tests added or changed, and any deployment or data migration requirement. This information determines what QA must retest.

Before moving to Ready for test, confirm:

• the code change is merged into the intended branch
• the named build contains the change
• the build is deployed to a testable environment
• configuration, schema, cache, and feature-flag changes are applied
• test data can reach the original condition
• known side effects or regression areas are noted

If the code is complete but deployment is pending, use a clearly owned waiting state or blocker field. Do not send the item back and forth between developer and tester to make dashboards look active.

For a deferred fix, state the target milestone or review date and the current risk treatment. “Backlog” without a trigger is abandonment disguised as planning.

Retest the claim and the surrounding risk

Retesting repeats the original failure conditions against the identified candidate build. Regression testing examines nearby behavior that the change could disturb. They are related but not interchangeable.

Suppose a fix changes rounding in the order total service. The retest reproduces the exact currency, discount, tax, and quantity that failed. Focused regression then covers another currency, a refund calculation, boundary quantities, and the displayed total across API and UI. The developer’s cause analysis should influence this selection.

Attach concise evidence to the result:

When a retest fails for the same reason, reopen the defect rather than creating a duplicate. When it reveals a separate cause or impact, link a new defect so ownership and history remain clear.

Closure means the agreed condition is satisfied. It does not require QA verification in every case, but exceptions need explicit authority. A production-only emergency fix might close on monitoring evidence and product approval when staging cannot reproduce the condition.

Handle non-fix outcomes without losing the risk

Duplicate defects should link to a canonical item and copy any unique evidence before closure. A report is not a duplicate merely because two symptoms occur on the same page.

For Cannot reproduce, document attempts, environments, and missing instrumentation. Set a reopen trigger such as a new correlation ID or another affected tenant. Repeated customer impact with poor observability is an observability problem, not proof that no defect exists.

Works as designed requires a referenced expectation and product confirmation when the expectation was unclear. Won’t fix requires a decision owner, rationale, impact acceptance, and mitigation where applicable. Deferred needs a review point. These controls preserve risk that would otherwise disappear from the active queue.

Reopening should be normal when new evidence invalidates closure. Measure careless closure separately if needed, but do not discourage a tester from correcting the record.

Operate the workflow by aging and evidence

Status counts alone do not reveal flow health. Review how long items remain in each state, especially New, Ready for test, and Blocked. Segment by severity and product area so a pile of low-impact cosmetic work does not conceal one stalled release risk.

Useful operational signals include:

• time from New to triage decision
• time from Ready for test to first retest
• percentage of reopened items and their reasons
• defects closed without the required evidence
• blocked age by dependency owner
• customer-reported defects mapped to missed test or review controls

Do not turn these into individual performance scores. A high reopen rate might reveal weak fixes, vague requirements, wrong build selection, or insufficient test data. Sample the records and determine the cause before setting a target.

Audit the workflow quarterly or after a painful release. Remove statuses with no unique owner or decision. Add a state only when an important queue is currently invisible. Test the definitions using three recent defects and ask each role what must happen next. If answers differ, the lifecycle still relies on tribal knowledge.

The workflow succeeds when anyone can open a defect and reconstruct the decision: what failed, why it mattered, who accepted action, which build changed, how the claim was tested, and why the item stopped moving. Closure is then an evidence state, not a colored button.