Defect management
Defect management is the process a team runs over every defect it finds and the policies that govern it: how each one is classified, who owns it at each stage, when it escalates, when it can be closed, and which measures are read off the queue as a whole. Bug tracking keeps the record; defect management decides the rules the record is kept by.
The longer version
The policies cover a defect's whole life. At intake, a classification rule says what a report must contain to be accepted and how its type, severity and priority are set. An ownership rule says who holds a defect in each state, so that nothing sits in a queue with no name on it. An escalation rule says what happens when a defect of a given severity has waited longer than the team accepts. A closure rule says who verifies a fix and against which environment. A measurement rule says which questions the queue must be able to answer: open count by severity, time from report to triage, reopen rate, defects found after release.
Bug tracking is the practice the policies govern, and the two are confused because the same tool carries both. Tracking is the record: every defect written down, distinguishable, current. Management is the layer above it, the decisions about what a record has to look like and what happens to it on a schedule. A team can track well and manage badly, keeping a clean record in which critical defects wait a month because nobody wrote down who escalates them. The bug life cycle names the states; management decides who moves a defect between them and how fast.
Management fails in the gap between the written policy and the tracker's actual behaviour. The policy says severity is set by the reproducer; the tracker lets the reporter set it and nobody re-rates. The policy says a fix is verified in staging; the developer closes the ticket on merge. The policy says defects found by customers are tagged so they can be counted; the tag is optional and rarely applied. Each gap silently changes what the measures mean, so the reopen rate looks fine while users keep reporting the same fault. The remedy is to make the tracker enforce the policy, with required fields and states that only certain roles can set.
Common questions
What is the difference between defect management and bug tracking?
Bug tracking is the record of every known defect and its current state. Defect management is the set of rules that record is kept by: how defects are classified, who owns them in each state, when they escalate and how they are measured. Tracking is the ledger; management is the policy that decides what goes in it and when.
What does a defect management process include?
Intake rules for what a report must contain, a classification scheme for type, severity and priority, an ownership model for every state, escalation thresholds for defects that wait too long, a verification and closure rule, and a small set of measures read off the queue, such as open defects by severity and defects found after release.
Who is responsible for defect management?
A QA lead or test manager usually owns the policy, because they see the whole queue, but the rules bind everyone who touches a defect: reporters who must supply the required fields, developers who must not close on merge, and product owners who set priority. A policy owned by QA and ignored by engineering is a document rather than a process.
When should a defect be escalated?
When it has waited in a state longer than its severity allows, when a fix has been reopened more than once, or when the owner of that state has not acted and nobody else can. Escalation is written per severity level in advance and names the role that receives it, usually a QA lead or engineering manager, so that raising a defect is a rule being applied rather than a complaint being made.
What does defect management look like in an agile team?
Defects enter the product backlog alongside stories, and the classification, ownership and closure rules are applied at refinement and in the daily stand-up rather than in a separate defect meeting. Triage happens as reports arrive, a defect found against work in the current sprint is fixed in that sprint, and escalation goes to the product owner. The measures are read at the retrospective, where the process can actually be changed.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.