What Is Defect Management? Severity, Priority and the States in Between

Defect management is what happens to a bug between somebody noticing it and somebody confirming it is gone. It is a process, not a tool: the states a defect moves through, who moves it, and how the team decides which ones get fixed first.

Most teams have one whether or not they wrote it down. The undocumented version is usually “put it in the tracker and hope”, which works until there are more defects than anybody can hold in their head - typically about thirty.

The life cycle

The states have different names in different trackers, and the shape underneath is the same.

• New. Reported, nobody has looked at it yet.
• Triaged. Somebody has read it, confirmed it is real, and decided how urgent it is.
• Assigned. It has an owner.
• Fixed. The owner believes it is done. Nobody else believes anything yet.
• Verified. Somebody who is not the owner has confirmed it against the original report.
• Closed. Finished.

Two other endings are legitimate and often mishandled. Rejected means it is not a defect - the behaviour is intended, or the report described a misunderstanding. Deferred means it is real and not being fixed now. Both need a reason written in the ticket, because the alternative is the same defect getting reported again in six weeks by somebody who has no way to know it was already considered.

The step teams quietly skip is verification. A defect closed by the person who fixed it is a defect closed on one person’s opinion, and the fix that did not actually cover the reported case is a common enough experience to have its own reproduction problem.

Severity and priority are not the same thing

This is the confusion worth clearing up, because it causes arguments that look like disagreements about the defect but are actually two people using one word for two ideas.

Severity is how bad the behaviour is. Data loss is severe. A misaligned icon is not. It is a property of the defect itself and it does not change because the calendar changed.

Priority is how soon it gets fixed. That is a business decision, and it depends on who is affected, how many, whether there is a workaround, and what else is competing for the same week.

The two come apart in both directions, which is what makes them worth separating:

High severity, low priority

A crash in an admin screen used twice a year by one person who knows the workaround

Low severity, high priority

The company name misspelled on the pricing page, seen by everybody, fixed this morning

Trackers that offer only one field force you to average the two into a number that means neither. If yours does, say which one it means and write it down, because otherwise half the team is ranking by damage and the other half by urgency.

Who triages, and how often

Triage is a decision, so it needs somebody who is allowed to make it. On a small team that is one person going through the new queue each morning. On a larger one it is a short recurring meeting with a developer, a tester and somebody who speaks for the product.

What matters more than the format is that it is regular. A queue triaged when somebody remembers grows a tail of defects nobody has read, and the cost of that is not the untouched tail - it is that nobody trusts the queue any more, so real ones get reported into chat instead.

Triage needs three answers per defect, and no more: is it real, how bad is it, who owns it. Anything longer is design work happening in the wrong meeting.

Reports decide how fast the process runs

Every state after “new” depends on how good the report was.

Triage cannot judge severity without knowing what actually happened. The owner cannot fix what they cannot reproduce. Verification cannot confirm anything unless the original steps are still written down. A vague report does not simply cost the reporter’s five minutes - it costs a round trip at every stage, and each round trip is a day.

This is where most of the time goes. Not in the fixing, in the asking again.

Our bug report guide has the shape that survives triage: what happened, what was expected, the steps, and the environment. Ask for those four and most of the round trips stop happening.

Metrics that mislead

Three numbers get counted because they are easy to count, and each one is worth reading carefully.

• Open defect count. Goes up when testing gets better, which is the opposite of what it looks like. Falling to zero more often means people stopped reporting than that the software improved.
• Defects per developer. Rewards whoever touches the least code. Do not.
• Time to close. Useful, but it measures the process as much as the work - a week spent waiting for the reporter to answer a question counts the same as a week of debugging.

The one worth watching instead is reopen rate: defects marked fixed that came back. It is a direct measurement of whether “fixed” means anything on your team, and unlike the others it is hard to game.

The short version

Six states, a written reason for anything rejected or deferred, and verification done by somebody other than the person who fixed it. Severity is how bad, priority is how soon, and they are different fields. Triage on a schedule rather than when somebody remembers. And most of the time saved is saved at the start, in the report - a defect that arrives complete moves through the whole process without anybody having to ask a question.