Quality Ownership Models

## What "quality ownership" names Quality ownership is the question of **who is accountable for knowing whether a change works** — not who runs the checks, but who is answerable when something ships broken. Every organisation answers it, usually by accident, through the shape of its teams. Four answers recur often enough to have names. ## The four models **Independent test group.** A group of testers sits outside the delivery teams. Work is completed, handed over, verified, and defects are handed back. The argument for it is objectivity and skill concentration: the testers did not write the code, so they carry none of the author's assumptions, and because they are together they build deep craft — data design, exploratory technique, tooling — and can be pointed at whatever is riskiest this month. It also gives specialised concerns (a compliance pass, an accessibility audit, a certification run) a place to live. **Embedded testers.** One or more testers belong to a delivery team permanently. They attend its planning, argue about a requirement before code is written, work through the tricky cases alongside the author, and are measured on what the team delivers rather than on what they catch. Feedback distance collapses from days to minutes. The cost is that testing skill is now distributed one person deep per team: the embedded tester has no peer group unless the organisation builds one deliberately. **Whole-team quality with no dedicated tester.** Every engineer is expected to test — their own work and each other's — and there is no separate role. This is common in small companies and in teams with strong automated checks. It removes handoff entirely, but it also removes the person whose full-time job was to think adversarially. It fails quietly: the team keeps testing the paths it already imagined, and nobody is looking for the case nobody thought of. **Coaching or enabling function.** A small group whose product is other people's capability. It runs technique sessions, builds shared harnesses and data tooling, reviews a team's approach to a risky release, and helps a new team get started. It does not own sign-off and does not act as a queue. Its failure mode is being quietly reclassified as a test group the moment a deadline gets tight. ## The failure modes to name **Over the wall.** With an independent group, the two sides can end up with opposing objectives: delivery is measured on features shipped, the group on defects found. Work is thrown over the wall, defects come back over the wall, and neither side owns the outcome. The symptom is a long, lumpy interval between writing a behaviour and hearing it is wrong, and defect reports about code the author has already changed twice. **Rubber stamp.** The opposite degeneration. Sign-off still exists on paper, but it is performed without evidence — approvals arriving seconds after the request, whole batches approved at the end of a period, approval by someone with no access to the environment. The ceremony survives; the verification does not. **Skill concentration versus spread.** An independent group concentrates deep skill in one place, where it is available to everyone but slowly. Whole-team quality spreads shallow skill everywhere, where it is immediate but nobody is expert. Embedded testers and an enabling function are two different attempts to get both, and each has a real cost. ## What changes between models Three things move as you go across the spectrum. **Handoff latency** — the interval between a change existing and someone competent judging it — shrinks as testers move closer to the team. **Who signs off a defect** moves from a separate authority to someone inside the team, which is faster and less independent. **Whose objective is served** changes: a group with its own targets will optimise for its own targets, and that is a structural fact, not a character flaw. ## How to answer this in an interview Name the four models, give one sentence each, then say the thing that distinguishes a candidate who has lived it: no model is correct in the abstract. A regulated product with a certification gate and a consumer web product on daily releases genuinely want different shapes. Real organisations are hybrids — embedded testers plus a small enabling group is the most common modern arrangement — and the shape you inherit is usually a fossil of how the company grew, not a decision anybody made. The useful skill is diagnosing which model you are actually in and what its specific failure mode is costing.