The Defect Lifecycle: From Bug Report to Closed

The defect lifecycle is the set of states a bug moves through from the moment someone reports it to the moment it's verified as fixed and closed. A typical lifecycle runs New, Triaged, In Progress, Fixed, In Test and Closed, with side branches for Rejected, Duplicate, Deferred and Reopened.

Getting the states right matters less than getting everyone to respect them.

The stages, one by one

1. New. Someone has reported a problem. Nothing is known yet beyond what they wrote.
2. Triaged. A lead has confirmed it's real, set a priority and decided who owns it.
3. In Progress. A developer is working on the fix.
4. Fixed. The developer believes it's resolved and the fix is in a build.
5. In Test. A tester is verifying the fix on the right environment.
6. Closed. The fix is verified. The bug is done.

The most important gap is between step 4 and step 6. "Fixed" is a claim. "Closed" is a fact someone checked.

The branches that cause trouble

Real bugs don't follow the happy path. Plan for these:

• Duplicate. The same bug reported twice. Merge them rather than closing one, so you keep both reporters' details.
• Can't reproduce. Send it back with a specific question, not just a status change.
• Rejected. Working as designed. Say why, in writing, so it isn't re-raised next month.
• Deferred. Real, but not now. Give it a review date or it becomes permanent.
• Reopened. The fix didn't hold. Every reopen should carry a reason, because a pattern of reopens is a quality signal worth watching.

Need proof your work was tested? See how Flow records test runs and sign-off as evidence. Get started with Flow →

Rules that keep the lifecycle honest

A workflow diagram on a wiki page doesn't enforce anything. These rules do:

• Only testers move a bug from In Test to Closed.
• A bug can't skip from New to In Progress without triage.
• Every status change records who made it and when.
• Severity is set at triage, not by the reporter alone.

The more of this the tool enforces for you, the less the team has to remember. For the reporting side, see our guide to bug tracking.

Modelling the defect lifecycle in Jira

Jira is the default for many software teams, and for good reason: its workflow engine is highly configurable and its marketplace is huge. You can model almost any defect lifecycle there. Teams that also need test management in Jira typically add a marketplace app, and client-facing bug intake usually means Jira Service Management, a separate product. If you're weighing a Jira alternative, the question is whether you want to assemble those pieces or have them in one place.

How Flow handles the defect lifecycle

Flow treats the lifecycle as a process you draw, not a convention you hope people follow.

• Process Flow. Draw your defect stages visually; each stage becomes a board column, and transition rules control which moves are allowed.
• Governed stages and provenance. Mark a stage so only automation can move tickets into it, and every move records whether a person or the automation made it.
• Merge duplicates with history preserved, so neither report's details are lost.
• Failure history from test runs. When a fix fails verification, the ticket's failure history shows it, making repeat offenders easy to spot.

Urgent production defects can follow a dedicated hotfix process instead of waiting for the next release, and Livex Flow tracks those separately as hotfix releases.