Defect life cycle

A defect life cycle is the workflow a tracker enforces: the states a report can occupy, who is permitted to move it between them, and what has to be true for each transition. A minimal version runs new, assigned, fixed, verified, closed, with rejected and reopened as the branches that matter. The specific names are unimportant and every organisation invents its own. What matters is that the set is small, that each state has an owner, and that everyone reads a given state the same way.

The purpose is to make the position of every known problem answerable without a meeting. A well-run cycle tells you how many defects are waiting on a developer, how many are waiting on a tester, and how many have been sitting in a state nobody owns since March. That last figure is usually the interesting one. Workflows fail not by being wrong but by growing: once there are fourteen states, people pick whichever seems closest, and the board stops describing reality.

The transitions that carry weight

• Fixed to verified. Only the person who can reproduce the original problem should make this move, on the build containing the change, because a developer marking their own work as done removes the check the state exists to provide.
• Rejected, which needs a reason recorded. Cannot reproduce, works as designed and duplicate are three different outcomes with three different follow-ups, and collapsing them loses the thread.
• Reopened, which is worth counting on its own. A high reopen rate points at reports that are too vague to fix correctly, or fixes being verified against the wrong build.
• Deferred, which should require a named owner and a date. Without both it is a state where defects go to be forgotten while still appearing to be managed.

Count the age of each defect in its current state, not just in total: a bug three weeks old and moving is healthy, while one that has sat in triage for three weeks is a process failure.