Software bug life cycle: states and who owns them

A filed report still has work left on it. The software bug life cycle is the sequence of states that work passes through until the ticket needs nothing else. Jira, Linear, and GitHub Issues use their own labels. The ten names below are the ones this phrase usually refers to. Map them onto the statuses your tracker actually has.

The path a fix takes is: New → Assigned → Open → Fixed → Retest → Verified → Closed. From New, triage can send the report to Rejected or Deferred instead of Assigned. From Retest, a failed check goes to Reopened, which returns the bug to Open.

States

Two names get used for more than one moment.

New and Open. Some trackers call the first state Open, and use In Progress once someone is working. On this page, New means logged and unreviewed. Open means accepted, and someone is investigating or fixing it.

Deferred and Rejected as endings. Some trackers leave those two as the last status. Others move the ticket to Closed and keep the reason. The record either way is one of two decisions: a real defect, not in this work, or a report the team will not fix. A deferred bug still needs an owner and a reason. A rejection still needs the reason on the ticket, or the same report comes back as New.

Severity and priority are not states. Severity is the damage: a crash, a broken flow, a wrong label. Priority is when this team will work on it. A crash in a flow nobody uses can be severe and still wait. A wrong price on the homepage can be a small break and the first thing in the queue. Triage writes both down, then chooses Assigned, Deferred, or Rejected.

Who moves a bug

Four roles cover the moves. On a small team one person often holds two of them, and the useful part is noticing when they switch.

• Reporter. Writes New. That can be a tester, a support reply, a user, or a check that failed.
• Triage. Decides the report is a defect someone will fix, a defect that waits, or a report to reject. Names the assignee. This is a product manager, a QA lead, or the developer who is about to do the work and is spending a few minutes choosing.
• Assignee. Moves Assigned to Open when they start, and Open to Fixed when they have a change. Moves it to Retest when that change can be checked.
• Retester. Runs the original steps on the build that contains the change. Verified, then Closed, when the failure is gone. Reopened when it is not. The assignee is a weak witness for their own fix. A second person is the point of Retest. With one person on the team, that means doing the check later, from the written steps, rather than from memory of the change.

Where it sticks

Three places show up on the ticket itself.

New, and no triage. The report waits because nobody's job is to accept, reject, or defer it. Assigned never happens, so neither do the states after it.

Fixed → Retest → Reopened → Open, more than once. The state only says the check did not hold. The notes say which of these it was: the steps in the report do not produce the bug; the fix was checked on a different build or environment than the report; the original failure is still there; the retest found a different failure and it was written onto the same ticket. Splitting that last case into its own report keeps the original bug's history readable.

Deferred, with no time to look again. The defect is acknowledged and then left. A deferred bug nobody reviews is finished in practice and still open in the tracker. The review date belongs on the ticket next to the reason.

What New has to carry

The assignee's first task is to reproduce the failure. A report that supports the move from New to Assigned has the steps in order, what should have happened and what did, and the environment: URL, browser, and whether the account was signed in. It also has evidence taken while the failure happened: the screen, the console, and the requests. The field-by-field version of that report is how to write bug reports.

When the failure comes from a Monito check, that evidence is already on the run. The run records screenshots, console logs, and network requests, and it includes a bug report when the check finds one. A run with no login also records a video. A run that signs in keeps masked screenshots instead of a recording. The person who receives the bug can open the run and see the failure.

Life cycle of the bug, and of the testing

The software testing life cycle is the plan for finding failures: what to test, running it, and writing down what failed. The bug life cycle starts at one failure. A single test run can open several bugs. A bug can stay open after the test that found it has finished.