Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Short definition
The set of practices by which a development team reduces the number of defects it produces, as opposed to the arrangements that handle defects once produced.
Full definition
In ordinary industry usage, "quality" indiscriminately covers the state of the product shipped, the satisfaction perceived by the user and the activity of the test teams.
In the articles on this blog, the phrase designates a precise perimeter: what acts on manufacturing. It covers developers' responsibility for what they ship, the refusal to code on a strong ambiguity, the formalization of expected behaviour before implementation, the automation of checks, and the quality framework written by QA. It stands term for term against the Zero bug policy, which bears on the stock of known defects: the first prevents the stock from forming, the second forbids keeping it. Neither replaces the other.
Usage in the field
Arbitrating capacity between fixing and building, defining a quality policy, diagnosing a team whose defect flow doesn't fall despite fast fixes, discussing the legacy currently being manufactured.
Synonyms and variants
Upstream quality · production quality · defect prevention.
Not to be confused with
- Zero bug policy — the regime that forbids keeping a known defect without a decision; it bears on the stock, not on what feeds it.
- QA — the function that defines and verifies quality criteria; it is one of delivery quality's means, not its equivalent.
- Perceived quality — the user's judgment on the product, which depends as much on design as on the number of defects.
- Definition of Done — a list of conditions attached to a work item, which formalizes a threshold without saying how to reach it.
- Technical debt — a design weakness whose handling has been decided; it weighs on the capacity to ship, not on the state of what is shipped.
Examples
A team whose defect stock is empty but whose incoming defect rate hasn't moved has handled the stock without touching its delivery quality.
Giving developers the right to refuse a specification that is too vague is a delivery-quality decision, not a prioritization rule.
Ambiguities / debates
The word "delivery" is sometimes read as the moment of deployment, which would wrongly suggest a quality verified at the point of going to production — whereas the phrase designates everything that precedes it.
The exact perimeter stays loose: does product design belong to delivery quality, or only what goes from specification to deployment?