The Bug Lifecycle: A Status Workflow That Scales From 3 to 300 Engineers

A bug status workflow is the most over-engineered and under-thought artifact in most engineering orgs. Three-person teams invent fifteen statuses they never use. Three-hundred-person orgs let everything rot in a single "Open" column. The right answer is a small, fixed state machine where every transition has exactly one owner and every severity has its own clock.

This playbook gives you that state machine, the SLAs that hang off it, and the ownership map that keeps it honest. It is grounded in the ISTQB defect management model, Google SRE's incident roles, and DORA's 2024 metric reclassification. The BugMojo angle runs underneath: because the platform is AI-native, each status is simultaneously a UI control, an API endpoint, and a tool an AI agent can call.

The ISTQB Certified Tester Foundation Level syllabus v4.0 (mandatory since 9 May 2024) defines defect management as a workflow for handling individual defects from discovery to closure. It is deliberately abstract, structured as four activities: log the reported anomaly, analyze and classify it, decide a response (fix or keep as-is), and close the defect report. It does not prescribe status names, which is exactly why one model can stretch across team sizes. The eight states below are the concrete expansion of those four activities.

• New — Reported, not yet reviewed. Maps to ISTQB log.
• Triaged — Severity and priority assigned, owner set. Maps to analyze and classify.
• In Progress — A fix is being written.
• In Review — The fix is in code review or an open PR.
• Verified — QA or the original reporter confirmed the fix against the original repro steps.
• Closed — Done and shipped. The terminal state.
• Reopened (side-path) — A verified or closed bug regressed or failed verification.
• Will Not Fix (side-path) — A deliberate decision to keep the behavior as-is. Maps to ISTQB decide a response: keep it.

A three-engineer team can collapse this to five live states (New, In Progress, In Review, Verified, Closed) and handle triage in standup. A 300-engineer org adds Triaged as a formal gate, makes In Review map to a required PR, and puts Will Not Fix behind product sign-off. Same skeleton, more governance.

Do not set one global "fix bugs within N days" target. Tie SLAs to severity, and split each SLA into two clocks: a response target (first human acknowledgement plus triage) and a resolution target (reaching Verified or shipped). This mirrors the SLO-budget logic in the Google SRE book, where a faster error-budget burn rate pages a human sooner. Critically, severity is not priority: per BrowserStack, severity is an engineering-led measure of technical impact, while priority is set by product to decide timing. A critical crash in an internal-only testing tool can sit at low priority.

Measure adherence with DORA's failed deployment recovery time. The 2024 DORA report restructured its metrics into five and moved recovery time out of stability and into the throughput group, alongside change lead time and deployment frequency. That reframing is useful here: how fast you drive a Critical bug from New to Verified is a throughput signal about your delivery system, not just a stability footnote.

Ownership must be single-threaded per transition. The Google SRE book is blunt about why: without an explicit Incident Commander, the unmanaged alternative is multiple engineers independently making changes and a communication breakdown. The Commander holds high-level state and assigns work by priority. A bug workflow needs the same discipline, scaled down to one owner per arrow.

In a traditional tracker, a status only changes when a human clicks a dropdown. BugMojo treats each status as three things at once: a UI control, a tRPC endpoint, and an MCP tool an AI agent can invoke. The Model Context Protocol 2025-11-25 spec makes tools model-controlled: a client discovers them with tools/list and invokes them with tools/call. The same spec carries a hard guardrail — there SHOULD always be a human in the loop with the ability to deny a tool invocation. That contract is what lets an agent move work without removing human control.

The enabling data model is the polymorphic assignee: assignee_type is MEMBER or AGENT, and assignee_id points at whichever it is. An agent can own In Progress while a human still owns Verified. Because BugMojo's extension captures rrweb session replay, console logs, network requests, and screenshots, an agent like Claude Code or Cursor reads real reproduction context before it touches a status.

Drop this into your tracker config or your team handbook. It is the smallest version that still enforces owners and SLAs.

• States: NEW, TRIAGED, IN_PROGRESS, IN_REVIEW, VERIFIED, CLOSED, REOPENED, WONT_FIX
• Required gate: a bug cannot leave TRIAGED without a severity and an owner.
• Verification rule: only QA or the original reporter sets VERIFIED, and only against the original repro.
• Reopen rule: REOPENED routes back to TRIAGED, never straight to IN_PROGRESS, so severity is re-confirmed.
• SLA clocks: response = time in NEW; resolution = time from NEW to VERIFIED, bucketed by severity.
• Audit: every transition records actor (MEMBER or AGENT), timestamp, and from/to status.

Two cross-references close the loop. The New-to-Triaged step is where most workflows leak time and accuracy; the mechanics of doing it well are their own discipline, covered in the bug triage glossary entry. And because the SLA table above hinges on the severity-versus-priority distinction, it is worth internalizing why those two fields have different owners before you wire up your clocks.