What is the difference between a defect's origin phase and its escape phase?

## Two questions about one defect A defect record answers "what is broken" and "how do I reproduce it". Classification adds two more questions, and the point of this leaf is that they are **independent**: * **Origin** - in which activity did the defect come into existence? * **Escape** - which activity should have found it before now, and did not? The same defect almost always has different answers to those two. A wrong assumption written into a design note (origin: design) can survive review, unit testing and integration testing and be found by a user (escape: everything up to and including acceptance). Squashing both into one free-text "cause" field loses the distinction and, with it, the ability to act. ## Origin categories A workable closed list covers where decisions and artefacts actually get made: * **Requirement** - the behaviour was never specified, or was specified ambiguously or wrongly. The code faithfully implements what was written down. * **Design** - the specification was right; the structure chosen to satisfy it cannot, or a decision inside it is wrong. * **Code** - the design was right; the implementation of it is not. * **Data** - the executable is correct for its stated contract, but a data set violates an assumption that the contract never stated. * **Configuration** - the shipped artefact is correct; the value applied in some environment is not. * **Environment** - a platform, version, capacity, clock or locale difference in where the system runs. * **Third party** - a component nobody on the team authors behaves differently from its documented contract. Two rules keep the list usable. First, **pick exactly one origin per defect**, or the counts stop aggregating. Second, agree a written tiebreak for the overlaps, because the interesting defects all sit on a boundary. ## Escape phases The escape list is the sequence of checks a change passes through, roughly cheapest and earliest first: static analysis and review, unit testing, integration testing, system testing, acceptance, and then the field. The escape phase is **the last one that had a fair chance and missed**, not merely the phase in which the defect was eventually found. "Fair chance" is doing real work in that sentence. A unit test cannot catch a defect that only appears when two services interact; naming unit testing as the escape phase there is a classification error that sends effort to the wrong place. Conversely, if a unit test *could* trivially have caught it, escape belongs there even though the defect was actually found three phases later - the point of the field is to name the earliest cheap check that was missing, so ask "where is the cheapest place this could have been caught?" before you write it down. It is also worth distinguishing three very different escapes that look the same in a report: 1. **No check existed** at that phase for this kind of thing. 2. **A check existed and was wrong** - it asserted the buggy behaviour, or asserted nothing meaningful. 3. **A check existed and did not run** - it was skipped, quarantined, excluded from the pack, or the phase was cut for schedule. Each has a completely different fix, and only the first is about test design. ## Why the pair is the point Origin aims **prevention**: a run of requirement-origin defects says the specification process is where to invest, and no amount of extra testing will remove them. Escape aims **detection**: a run of defects escaping to the field through the same thin phase says the checks are in the wrong place, whatever their origin. Read the pair together and you get the containment gap - the distance between where a defect was born and where it was finally caught. A short distance is a healthy process even if the defect count is high. A long distance repeated across many defects is the signal worth acting on, because every phase in between is one you are paying for and not getting value from. A defect that never escapes at all - introduced in a design and caught by the design review - has an origin and no escape. That is the outcome you want, and recording those matters too; a classification scheme that only sees the failures cannot tell you which checks are working. ## Common traps **Fix location is not origin.** The fix frequently lands in the consumer of a bad component or a bad data feed. Where the change is made says nothing about where the defect came from. **"Human error" is not an origin.** Every origin category is reached by a person making a decision; recording the person adds nothing you can act on and costs you the honesty of the field. **Late is not automatically worse.** The claim that defects get dramatically more expensive the later they are caught is directionally well supported but the specific multipliers quoted are contested and often traced back to studies whose context does not match modern delivery. Argue from the concrete cost of *this* escape - who was affected, for how long, what the repair cost - not from a remembered number.