The economic proof that more testing is not always more value.
The static COQ curve finds the economic optimum; the dynamic curve tracks what it costs in practice.
A worksheet pairing the classic static cost-of-quality curve (where increasing defect-detection percentage first reduces total cost, then increases it) with a dynamic month-over-month model comparing a low-investment program to a high-investment program. Use the static model to set DDP targets; use the dynamic model to track actuals against plan.
Cost of Quality answers the board-level question: "how much testing is enough?" It quantifies the two halves of the trade-off — cost of conformance (testing, reviews, prevention) and cost of nonconformance (failures, rework, support, lost customers) — and finds the defect-detection percentage that minimizes their sum. Without the CoQ frame, testing budgets are argued in absolute terms; with it, they are defended as economic optimization.
Key Takeaways
Four things to remember.
CoN falls, CoC rises, CoQ is the sum
As DDP climbs from 0 to 1, cost of nonconformance falls (fewer bugs escape). But cost of conformance rises — slowly at first, then exponentially as the team pursues the last few percent of defects. Total CoQ is U-shaped; the minimum is the economic optimum.
The optimum is usually 0.7–0.8 DDP, not 1.0
For most commercial software, pursuing DDP above ~0.8 costs more in test effort than it saves in support / rework / revenue loss. Safety-critical and regulated contexts push the optimum higher (0.9–0.95). Knowing the industry band of your product sets the DDP target.
Dynamic CoQ tracks what the static model predicted
The static model sets the target; the dynamic model (month-by-month CoC and CoN) is what you report against. A program whose CoQ curve rises steeply after month 3 is buying less marginal quality per dollar than the model predicted — that is a signal to re-examine the test basis, not to add more testers.
Invest earlier, pay less total
The worked "Cad" vs. "Heroine" comparison shows the same effect the Metrics Part 4 whitepaper documents: programs with higher DDP targets from month 0 accumulate lower total CoQ over the program life, even when month-0 CoC is higher. Pay now or pay more later.
Why this exists
What this template is for.
The downloaded .xls has three sheets: the static COQ table (CoN, CoC, CoQ across 11 DDP levels from 0 to 1), a dynamic curve for a lower-DDP program, and a dynamic curve for a higher-DDP program. The column reference below documents every field; the instructions tell you how to calibrate the model against your own cost structure.
The columns
What each field means.
Expected latent defects entering the test phase. The static model normalizes to 1,000 for cleanliness; substitute your estimated count (see the bug-find-fix estimation template for this input).
Delivered × DDP. The count the test function actually finds.
Defects removed by test ÷ defects delivered to test. The single independent variable in the static model; sweep from 0 to 1 to trace the curve.
Normalized measure of customer-perceived quality. In the worksheet, quality maps monotonically to DDP but is lower than DDP because some escaped defects are low-impact. Use as directional, not absolute.
Costs you pay because of defects: rework during development, support costs, warranty, lost customer lifetime value, regulatory fines. Falls as DDP rises. Calibrate against your prior programs — CoN per escaped defect typically ranges $500–$10,000 depending on industry.
Costs you pay to prevent and detect defects: test labor, tooling, environments, reviews, training. Rises as DDP rises; rises exponentially near DDP = 1 because the last defects are the hardest to find.
CoN + CoC. The function to minimize. The worksheet's core output.
Calendar position within the program. Month 0 = program start; each row represents a reporting period.
Latent defects still present at month M. Decays as testing removes defects; simplest model is exponential decay at the program's DDP rate, compounded by cycle.
Static model · the U-curve
CoN falls. CoC rises. CoQ is U-shaped.
Sweep DDP from 0 to 1. The sum of conformance and nonconformance costs bottoms out around DDP 0.7–0.8 for most commercial software, then explodes as the last few defects get disproportionately expensive to catch. The optimum is rarely DDP = 1.
Static COQ model
CoC / CoN / CoQ across DDP — illustrative $K
Optimum band at DDP ≈ 0.89; right of that the CoC curve goes near-vertical.
The knee at DDP ≈ 0.93 is the inflection point — past it, you pay exponentially more per marginal percent. Safety-critical and regulated contexts push the knee right; consumer SaaS pushes it left.
Live preview
What it looks like populated.
Static COQ curve — sum is minimized between DDP 0.7 and 0.8 for most programs, then rises steeply as CoC explodes.
| DDP | Quality | CoN | CoC | CoQ |
|---|---|---|---|---|
| 0.46 | 0.1 | $553 | $46 | $599 |
| 0.58 | 0.2 | $437 | $58 | $495 |
| 0.67 | 0.3 | $355 | $67 | $422 |
| 0.74 | 0.4 | $290 | $74 | $364 |
| 0.79 | 0.5 | $236 | $79 | $315 |
| 0.84 | 0.6 | $188 | $85 | $272 |
| 0.89 | 0.7 | $145 | $96 | $241 ← optimum band |
| 0.93 | 0.8 | $106 | $200 | $306 |
| 0.97 | 0.9 | $70 | $1,270 | $1,341 |
| 1.00 | 1.0 | $37 | $10,100 | $10,137 |
Dynamic model · Cad vs. Heroine
Pay now or pay more later.
Two programs on the same product. “The Cad” targets DDP 0.46 — low monthly CoC in early months, but CoN grows every month because defects accumulate. “The Heroine” targets DDP 0.67 — higher monthly CoC from the start, but stays flatter over the program life. By month 6, cumulative CoQ tells the story.
Dynamic COQ · cumulative over 6 months
Cumulative CoQ — Cad vs. Heroine
Lower-investment program (Cad) ends with higher total. Counterintuitive until you draw it.
Same result documented in the Metrics Part 4 whitepaper: programs that invest earlier for higher DDP accumulate less total CoQ over the program life. The static model predicts the target; the dynamic model tracks what it actually costs.
How to use it
6 steps, in order.
- 1
Calibrate CoN per escaped defect. Use the Internal / External Failure worksheet from the test budget template as a starting point: test-cost-per-bug (internal) + maintenance-cost-per-bug (external) × likelihood-of-escape. Industry ranges are a sanity check only.
- 2
Calibrate CoC per detected defect. Total test-function investment ÷ total defects found = per-defect CoC. Expect higher per-defect CoC in your first year of measurement because fixed-cost investments amortize over fewer finds.
- 3
Sweep the static model across DDP 0 to 1 in 0.1 increments. Plot the three curves (CoN, CoC, CoQ) and mark the minimum. The minimum is your DDP target.
- 4
Set the dynamic model: define CoC as a steady monthly spend (your test function budget / months) and CoN as (defects-remaining-at-month-M × per-defect-CoN). Month-over-month CoQ should track the projection within ±10%.
- 5
If actuals diverge from the model after month 2, re-examine inputs: a runaway CoC says the program is investing in low-yield test activity; a stubborn CoN says DDP is lower than projected (see the Metrics Part 4 whitepaper for diagnosis).
- 6
Compare programs in the same portfolio using the dynamic model. The two worked examples ("Cad" and "Heroine") show the typical pattern: higher-DDP program has higher CoC from month 0 but lower cumulative CoQ by month 6 — earlier investment, lower total cost.
Context knobs · where does your band sit
Not one optimum. Three bands.
The U-curve is universal. Its minimum is not. Know which industry band your product sits in before you defend a DDP target to finance.
Methodology
The thinking behind it.
Cost of Quality originated in manufacturing quality economics (Crosby, Juran, Deming). Software engineering adopted it through Kaplan, Krishnan, and others in the 1980s–90s. The U-curve shape is empirical across industries; the position of the optimum varies.
The near-DDP = 1 asymptote is real. The last defects are disproportionately expensive because (a) they evade every test case you have designed, (b) they require new test-design thinking (mutation testing, property-based testing, chaos engineering, adversarial testing for AI systems), (c) they may require environments (production-scale load, rare inputs) that are expensive to construct. Most commercial software is value-negative past DDP 0.85–0.9.
Different product contexts move the optimum: safety-critical (aerospace, medical, automotive) moves it to DDP 0.95+ because CoN includes human-life cost; consumer SaaS moves it to DDP 0.7 because feature velocity compounds and CoN-per-escape is low; regulated financial services sit near 0.85 because CoN includes fines and brand damage.
In 2026 the static model still holds, but three things have changed the shape: (a) automation drives per-test-case CoC down, shifting the optimum right (higher DDP is newly economical); (b) production-telemetry and observability drive CoN down by catching escapes before customers do, shifting the optimum left (less test needed to hit the same risk level); (c) AI-assisted test authoring is pushing per-test-case CoC down further but introducing a new CoN category — AI-system unsafe outputs — that needs its own DDP target. Net effect: the curve is still U-shaped, but at a lower altitude for most programs than it was 10 years ago.
Take it with you
Download the piece you just read.
We keep this library free. All we ask is that you tell us who you are, so we know who to follow up with if we release an updated version. One-time form, this browser remembers you after that.
Related in the library
Pair this with.
Need a QA program to back this up in your organization?
If a checklist is not enough and you want help applying it to a live engagement, we can have a call this week.
Related reading
Articles, talks, guides, and case studies tagged for the same audience.
- Whitepaper
Evaluation Before Shipping: How to Test an AI Application Before It Hits Production
The release-gate playbook for AI features. Covers the five evaluation dimensions, how to build a lean golden set, where LLM-as-judge is trustworthy and where it lies, rollout mechanics with named exit criteria, and the regression suite that keeps a shipped AI feature from quietly rotting in production.
Read → - Whitepaper
Choosing the Right Model (and Knowing When to Switch)
A practical framework for matching LLM model tier to task. Covers the four axes (capability, latency, cost, reliability), cascade routing patterns that cut cost 60 to 80 percent without measurable quality loss, switching costs you did not plan for, and the worked economics at 10K, 100K, and 1M decisions per day.
Read → - Whitepaper
Beyond ISTQB: A Multi-Domain Certification Roadmap for Technical L&D
Most engineering L&D programs over-index on a single certification family, usually ISTQB on the QA side, AWS on the infrastructure side, and under-invest across the rest of the technical domains the org actually needs. This paper covers a multi-domain certification roadmap (QA, AI, cloud, data, security, project management, software engineering) with sequencing logic for each level of the engineering ladder, plus the maintenance discipline that keeps the roadmap relevant as the technology shifts underneath it.
Read → - Guide
The ISTQB Advanced Level path, mapped
The Advanced Level landscape keeps changing — CTAL-TA v4.0 shipped May 2025, CTAL-TM is on v3.0, CTAL-TAE is on v2.0. This guide maps all four core modules, prerequisites, exam formats, sunset dates, and which module a given role should take first. Links directly to the authoritative istqb.org syllabi.
Read → - Whitepaper
Bug Triage: A Cross-Functional Framework for Deciding Which Defects to Fix
Bug triage is the cross-functional decision process that converts raw defect reports into prioritized action. Done well, it optimizes limited engineering capacity against risk; done poorly, it becomes a backlog-management ritual that neither fixes the important defects nor drops the unimportant ones. This whitepaper covers the triage process, the participants, the six action outcomes, the four decision factors, and the governance disciplines that keep triage effective in continuous-delivery environments.
Read → - Whitepaper
Building Quality In: What Engineering Organizations Do from Day One
Testing at the end builds confidence, but the most efficient quality assurance is building the system the right way from day one. This whitepaper covers the upstream disciplines — requirements clarity, lifecycle selection, per-unit programmer practices, and continuous integration — that make system-level testing cheap and fast rather than the only thing holding a release together.
Read →
Where this leads
- Service · Quality engineering
Software Quality & Security
Independent test programs, security testing, and quality engineering for systems where defects cost real money.
Learn more → - Solution
Risk Reduction & Clear Decisions
Quality programs and decision frameworks that shift risk discussions from anecdote to evidence.
Learn more → - Solution
Reliable Software at Scale
Quality engineering programs for organizations whose software is now operationally critical.
Learn more →