Defect Management

Defect density is a count of confirmed defects divided by a size unit — a thousand lines of code, a functional size unit, a module, a feature. Change the unit and the same product scores differently.

Origin phase is where the defect was introduced - the requirement, design, code, data or configuration work that created it. Escape phase is the last check that should have caught it and did not. Every defect has both.

The symptom is what was observed. The condition that produced it is the specific state or input that made the code fail that time. The weakness is the missing guard or assumption that allowed the whole family of failures.

Severity measures a defect's technical impact — how badly the product's behaviour breaks. Priority measures business urgency — how soon it should be fixed relative to other work. Different people set them, and the two values move independently.

A tracked defect moves through new, triaged, assigned, fixed, verified and closed, with side exits to rejected, deferred and reopened. The reporter files it, triage accepts and assigns it, a developer fixes it, and someone other than the fixer verifies it before close.

Match the technique to what you already know. A why-chain fits a single causal line you can walk back, a fishbone diagram fits an unknown cause spread across categories, and a fault tree fits a failure several routes can each produce.

Escaped, repeating, costly and undetectable defects earn an investigation; a typo caught in review does not. Blanket rules fail alike: investigating everything turns the work into a form nobody reads, investigating nothing pays for the same weakness again.

Reach, frequency and the absence of a workaround. A cosmetic defect on a path every user crosses, hit on every attempt, with nothing the user can do about it, outranks a crash reachable only through a configuration almost nobody runs.

They assert different things: not a bug means the product behaved correctly and the report was mistaken; duplicate means another open record already covers it; cannot reproduce means nobody could make it happen again; works as designed means the behaviour matches the specification, so changing it needs a specification decision.

Walk the chain of checks the change passed through, find the earliest one that could cheaply have caught it, and decide whether that check was absent, wrong, or skipped. That answer, not the phase that reported it, is the escape phase.

Remove or simplify one factor at a time - steps, data, flags, concurrency - resetting and re-running after each change. Keep removals that still fail, restore the ones that stop it, and finish when nothing else can go.

Ask which single artefact would have to have been different for the defect never to exist: the logic, a data set, a value applied to one environment, or a component the team does not author. That artefact names the origin.

Rejecting one value removes one occurrence, not the reason that value was dangerous. The weakness stays: the boundary nobody checked, the assumption two components did not share. So a neighbouring value, or the same value by another route, still fails.

Invite whoever can show the material that settles a link: the person who made the change, whoever can reproduce the failure, whoever owns the data or configuration involved. Without them the session produces the most plausible story, not an explanation.

Report failures over a stated number of attempts on a named build, the conditions that raise or lower that rate, evidence captured from a failing run, and what you ruled out. "Fails sometimes" is not a report.

Normalise arrivals by test effort before believing the curve, then probe with something the suite has never exercised. A flat curve over falling effort, or over a suite that has already found everything it can, is not evidence of stability.

Choose by reach, cost and how soon each pays back. Refusing the failing value is cheap but covers one occurrence; a guard covers the family by the next release; a design change removes the class over months.

Each route reaches the same failure on its own, so closing one leaves the defect reachable. Decomposing as alternatives makes the other routes explicit, forces verification along each, and exposes any shared step where one change closes them all.

Audit each link on its own. Ask what would be different if it were false, and who can show the thing that settles it. A link nobody can point to anything for is an assertion, however well it reads.

Group defects by cause shape (same area, same missing check, same escape route), never by shared symptom. One pass forces an explanation that must account for every member, a far harder test than explaining one.

Perishable evidence decides. Investigate before the fix only when the failing state is the evidence; otherwise preserve it, fix, then explain, because the change the fix required is itself evidence. Ownership follows the evidence: the fixer plus the context holder.

Bring evidence, not adjectives: measured reach, failure frequency, who performs the workaround and its recurring cost. Ask to rank above one named competing item, and if the answer stands, record the accepted risk and the trigger that reopens it.

Agree a confirmation criterion before the fix lands, replay the reported steps on a named build containing the fix, and get enough evidence that a pass means something — a forced-condition harness or a stated number of clean cycles — verified by someone other than the fixer.

Refuse the single per-team target and offer paired measures instead: every efficiency number gets a counter-measure, definitions are published and frozen, trends beat thresholds, and nothing is wired to ranking or pay.

Pick the highest rung on the containment ladder the class can afford: make it unrepresentable by design, else catch it mechanically with a static rule if it has a machine-checkable signature, else pin one behaviour with a regression case. Accepting and monitoring is a legitimate fourth answer.

The paragraph is the wrong output. Either narrow the funnel to few investigations, each owned, timeboxed and ending in one committed change, or keep breadth and cut depth with a two-field note feeding a monthly review of defect classes.

Deferral is an explicit, owned decision, not a queue that fills by default. Ship a defect as a known issue only when its harm is bounded and reversible, a workaround or accepted-risk statement exists, an owner and revisit point are named, and support and users are told.

Defect removal efficiency is the share of the defects present at a stage that the stage actually caught: defects found there, divided by that count plus the ones that escaped it and were found later, as a percentage.

It replaces prose with a few independent attributes drawn from fixed short lists - what kind of defect, whether something was missing or incorrect, what surfaced it, what it affected - so defects can be counted and compared instead of only read one at a time.