Defect Lifecycle States

A defect report sits in the queue for 40 days. It was new for 3 days, then assigned for 2, then 'fixed' — except the fix went to the wrong branch, so it spent 9 days in re-open, then 14 in a state someone labeled 'on hold' that no workflow defines, and it is now invisible in a triage view nobody filters. The bug took 20 minutes to actually fix. The lifecycle exists because defects do not stall for technical reasons — they stall because nobody owns the next transition. Every state answers one question: who must do what to move this forward, and how do we know when they are done?

The standard lifecycle, with each state's contract:

[New] → [Assigned/Confirmed] → [In Progress] → [Fixed] → [Verify/Retest] → [Closed]
             ↓                        ↓              ↓
        [Rejected]              [Deferred]    [Re-opened] → back to In Progress

Read the table as a set of ownership contracts rather than labels, because that is how the 40-day defect happened. 'New' without a triage owner means confirmation is nobody's job. 'Fixed' without a commit reference means the tester cannot find what to verify. 'Verify' without a deployed build means retesting against the old version and the pointless re-open loop that follows. The most valuable columns are the ones teams skip: entry and exit conditions per state.

Two lifecycle facts interviewers probe. First, rejected is a first-class outcome, not a failure: 'works as specified' (the behavior matches the requirement — the requirement may need a change request), 'not reproducible' (with the conditions you tried listed — never a bare verdict), and 'by design' (with the product owner's confirmation) all close defects legitimately, and a tester who never rejects anything is rubber-stamping. Second, re-open is evidence-driven: a closed defect comes back only with fresh evidence — the build number where the retest failed, the new stack trace, the regression case that caught it — because a re-open without evidence is indistinguishable from a retest against a stale build, the most common false re-open in existence.

Most lifecycle disputes live in the non-forward transitions, and each one is defined by the evidence it requires. Handle them with consistent proof and your defect queue becomes trusted; handle them loosely and triage meetings become debates about what the tool even means.

Rejected. Three flavors, each needing different proof. Not a defect / works as specified: the observed behavior matches the spec — the fix is a requirements change request, not a code fix, and the report should say so explicitly ('behavior matches REQ-118; if the intent is different, file a change request against the requirement'). Not reproducible: only close with the reproduction attempt documented — the builds tried, the environments, the steps deviated from, and an invitation to reopen with new information; a bare 'cannot reproduce' verdict from a developer with no data is the fastest way for QA-developer trust to collapse. By design: cite the product owner's confirmation and the decision record; the designer of the behavior is the authority, not the developer's intuition.

Duplicate. Only valid when one defect causes the other — link the original as the master, state the suspected common root ('both traces converge on the same serialization error'), and close the copy. Duplicates matter statistically: if five reports trace to one root cause, the defect count is one with five sightings, and the sighting count is real risk information — it belongs in the triage notes even though the tracker shows one open item.

Deferred. The most abused terminal, because it feels like a solution. A legitimate deferral names: the target release ('scheduling fix for 4.13', never 'later'), the accepted impact during the deferral period ('admin users see stale counts for up to 24h'), the approver (product, since deferral is a business risk decision), and the trigger that would pull it forward earlier (customer escalation, data corruption evidence). A defect deferred without those four fields has not been decided — it has been hidden, and it will surface as a surprise in the next release's first day of testing.

Reopened. Reopening is correct in exactly two situations: the retest failed (fix did not resolve the original symptom — attach your new evidence), or a later change regressed the same area (attach the regression case and the introducing build if you have it). The classic anti-pattern is the re-open ping-pong: tester re-opens with no new data, developer closes as 'working on my machine', tester re-opens — the fix is a rule: re-open requires a failing test on a named build; without it, the discussion moves to a comment thread, not a state change.

A fifth transition deserves attention because it is where queues die: stalled states — Assigned, In Progress, Verify — where items age without an owner's action. Instrument the tracker with age targets per state (New → triage within 1 business day, Fixed → retest within 1 day of build availability, Verify failures → re-open within 1 day) and review the aging report at triage. The 40-day defect is always visible in that report three weeks before anyone feels its consequences — queue aging is the cheapest early-warning system a QA team can run, and it is the diagnostic to reach for when an interviewer asks 'how would you improve a team's defect process?'

The lifecycle you configure in Jira or Azure DevOps should describe how your team actually moves defects — and when it diverges, the tool wins the argument and the truth lives in comment threads. The failure looks like this: the tracker has five states, the team uses two of them, 'Fixed' means 'I think I fixed it' to one developer and 'merged to main' to another, and the tester learns to read commit logs because the states are meaningless. Customization is a design exercise, not a configuration chore.

Step 1 — draw the real flow first. Interview the team for two weeks of recent defects: who confirmed, who fixed, where verification happened, what the ambiguous moments were. The real flow usually has three or four states nobody's default template contains — 'fixed pending deployment' (merged but not yet in a test build) is the classic, and it explains most 're-opened but nothing failed' confusion.

Step 2 — define states with written entry/exit contracts (the table from the first chapter, customized). The team signs off on the definitions, and the definitions go in the tracker's description field — the one place a reporter actually looks. Fewer states with sharp definitions beat many states with vague ones: five well-defined states carry more process truth than twelve that people route around.

Step 3 — enforce the transitions that protect data quality. Configure required fields per transition: severity and environment on creation; commit reference on entry to Fixed; build number and result on exit from Verify; approver and target release on entry to Deferred. Required fields at the right transitions are the cheapest quality control in defect management — they make every state change carry the evidence the next actor needs.

Step 4 — instrument and review. Two reports run the process: the aging report (open items by state-age, catching stalls) and the flow report (count by transition per week: how many re-opens, rejections, deferrals). A rising re-open rate is a fix-quality or retest-environment signal; a rising rejection rate is a report-quality signal; a deferral pileup without target releases is a triage-discipline signal. Reviewing both at a weekly 15-minute defect-process sync keeps the workflow honest and gives the team a measurable basis for adjusting it — add a state only when two consecutive months of flow data show a recurring ambiguous transition, never on someone's preference.

For interviews, the composite scenario is 'the team's defect process is chaotic — what would you do?'. Structure the answer: diagnose with the two reports (aging shows where items die, flow shows which transitions are abused), define states with contracts and required-field enforcement at evidence points (commit ref into Fixed, build number out of Verify), and only then add or remove states — ending with the principle that the tracker's states are a shared language, and a shared language is maintained by definitions everyone can quote, not by the number of columns on the board. This lifecycle is the container; the next topic fills it with reports that developers can act on the first time — Writing Reproducible Bug Reports.