In plain English.

A test policy is the organizational artifact (one per enterprise) that states what testing exists for, how it decides what to do, who is accountable at which level, and what it is measured on.

Four governance questions. One page. Nothing optional.

• What is testing for? (mission)
• How does it decide what to do? (risk-based strategy)
• Who owns which level? (test-level ownership)
• What is it measured on? (KPIs)

Policy ≠ strategy ≠ plan. Collapsing them is the most common policy failure. One per org; one per program; one per release.

Effective. Efficient. Timely. Accurate. Useful.

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

• Effective, the information is actionable.
• Efficient, cost proportional to value.
• Timely, arrives in time to act.
• Accurate, distinguishes what's measured, inferred, unknown.
• Useful, answers a question the organization actually has.

Identify. Assess. Map. Report.

• Identification, structured risk-analysis session (FMEA or equivalent) from the general quality risk categories taxonomy plus product-specific failure-mode knowledge.
• Assessment, each risk scored for likelihood and impact; produces an RPN or equivalent aggregate.
• Mapping to effort, risk level determines test extent (extensive → broad → cursory → opportunity → report-bugs-only → none) and sequencing.
• Reporting, residual quality risk is the primary release-readiness artifact. See the four-approach ladder for risk-based test results reporting.

A policy that says "risk-based" has to name how risk is identified, assessed, and mapped. Without that, it's a statement of values, not a governance document.

Detect defects in units.

Key areas: functionality and resource utilization.

Modern additions:
Contract tests against internal APIs. Property-based tests for pure functions. Mutation tests as a coverage-quality check.

Defects in unit interfaces.

Key areas: functionality, data quality, interoperability, compatibility, performance.

Modern additions:
Consumer-driven contract testing (Pact, Spring Cloud Contract). Schema-compatibility tests. Service-level interaction tests on ephemeral infrastructure.

Defects in use cases and end-to-end scenarios.

Key areas: functionality, data quality, performance, reliability, usability, resource utilization, maintainability, installability, portability, interoperability.

Modern additions:
Distributed-trace verification. Chaos / fault injection. AI-system evaluation against held-out sets. Observability-signal correctness.

Readiness for deployment.

Key area: functionality.

Not all acceptance-test activities for all projects have defect detection as an objective. Many are readiness confirmations rather than discovery exercises.

Risk drives rigor.

• High-risk projects (regulated, safety-critical, mission-critical, heavily-customer-visible): each step formally with auditable artifacts.
• Medium-risk projects: each step pragmatically. Documented, reviewed, stored, not re-verified.
• Low-risk projects: lightly. Steps happen; artifacts minimal. Often in code (test names, PR descriptions) rather than separate documents.

The policy sets the bands. Each project's strategy specifies where it sits. Formality is not a virtue; fitness-for-purpose is.

Defect Detection Effectiveness.

Percentage of defects found at this level before they escape to a later level (or production).

• Industry baseline: ~85% at system integration test.
• Achievable in disciplined organizations: 95%+.
• See the Metrics Part 2 whitepaper for calibration.

Percentage of identified risks tested.

Percentage of identified risk items with at least one test designed and executed against them, weighted by risk level.

Unmitigated high-risk items are reported explicitly in every status cycle. No exceptions, no quiet deferrals. Unmitigated-high-risk is the failure mode most status reports hide.

Project-by-project. Long-term.

Production telemetry. AI evaluation.

• Production-telemetry feedback loop, the test function has a named role in interpreting production signals (error rates, SLO compliance, customer reports) and feeding findings back into test design. Testing does not stop at release.
• AI-system evaluation, for inference-primary products, the policy names the evaluation discipline (held-out eval sets, golden sets, slice metrics, calibration) and who owns model-release gating.

Example-based assertion testing is insufficient for probabilistic output. The policy has to say so.

Continuous delivery. Observability as surface.

• Continuous-delivery level mapping, map the four test levels to their CD equivalents: unit in pre-commit, integration in PR CI, system in staging against realistic load, acceptance via canary / progressive rollout with SLO gates. Levels exist; run continuously rather than sequentially.
• Observability as policy surface, structured logs, metrics, traces, dashboards are a first-class testable surface. "The system ships observability" is a release requirement, not a nice-to-have.

Keep them separate.

• Policy, strategy, plan. One per org, one per program, one per release. Do not collapse.
• Risk-based is a commitment, it names how risk is identified, assessed, mapped.
• Test-level ownership is policy, not project negotiation.

Two KPIs. Honest ones.

• Defect Detection Effectiveness and Risk Coverage. Two.
• Formality follows risk. High / medium / low bands. Set by policy, specified by project strategy.
• 2026 additions, production telemetry, AI eval, CD mapping, observability. All four, or the policy is stale.