The one-page test policy the whole org reads.
Mission, risk-based method, four test levels, two KPIs — and the modern additions that belong next to them.

[Company Name Here] exists in the quality function to effectively and efficiently provide timely, accurate, and useful quality-risk-management information and services to the organization.

• Effectively — the information is actionable. A defect report a product manager can prioritize. A release signal an executive can rely on. A coverage view a program manager can plan against.
• Efficiently — the cost of producing the information is proportional to its value. Testing is an investment; the policy constrains the testing function to spend in proportion to risk.
• Timely — information arrives in time to act on it. A post-release finding is not a test result; it is a production incident.
• Accurate — reports distinguish what is measured, what is inferred, and what is unknown. Precision is not confidence.
• Useful — the information answers a question the organization is actually asking. A metric nobody uses is a budget line item, not a contribution.

Test levels promote mitigation of quality risk as early as possible and to the highest practical extent. Each level is owned by the group best qualified to design, execute, and interpret its tests.

Each group responsible for one or more test levels establishes KPIs for its test activities against the following two required areas. Groups may add a small number of additional KPIs; they may not drop these.

• Defect detection effectiveness (DDE) — the percentage of defects found at this level before they escape to a later level (or production). The industry baseline is roughly 85% DDE at system integration test; 95%+ is achievable in disciplined organizations. See the Metrics Part 2 whitepaper for calibration.
• Risk coverage and sequencing — the percentage of identified risk items that have at least one test designed and executed against them, weighted by risk level. Unmitigated high-risk items are reported explicitly in every status cycle.

Four additions we would include in a policy written today that were not required in the 2002-era original.

• Production-telemetry feedback loop — the test function has a named role in interpreting production telemetry (error rates, SLO compliance, customer-reported defects) and feeding findings back into test design. Testing does not stop at release; the policy names the loop.
• AI-system evaluation — for products whose primary job is inference, the test policy names the evaluation discipline (held-out eval sets, golden sets, slice-based metrics, calibration) and who owns model-release gating. Example-based assertion testing is insufficient for probabilistic output.
• Continuous-delivery level mapping — for continuously-delivered systems, map the four test levels to their CD equivalents: unit tests in pre-commit hooks, integration tests in PR CI, system tests in staging against realistic load, acceptance via canary / progressive rollout with SLO gates. The levels still exist; they run continuously rather than sequentially.
• Observability as policy surface — the policy states that observability artifacts (structured logs, metrics, traces, dashboards) are a first-class testable surface. "The system ships observability" is a release requirement, not a nice-to-have.