Acceptance Test¶
Criteria verification — instantiates Summative Certification
Certifies that a delivered system or product meets every pre-agreed acceptance criterion before it is formally accepted and handed over.
Acceptance Test is the endpoint check that decides whether a delivered thing may be formally accepted, by exercising it against a fixed set of criteria that were agreed before the work was done and recording a pass or fail for each one. Its defining move is that the standard is settled in advance and the verdict is binary and contractual: acceptance transfers the deliverable — and usually triggers payment, handover, or go-live — so the question is never "how good is this?" but "does it satisfy every criterion we agreed to?" It certifies an artifact rather than a person, and it trusts pre-negotiated, objectively checkable criteria rather than expert impression or holistic judgment.
Example¶
A city transit agency has paid a vendor to build a replacement fare-collection system: new gates, card readers, and a back-office reconciliation service. Before the build began, the two sides signed an acceptance-criteria list — a few dozen line items such as "a valid card is read and the gate opens in under 500 ms," "a declined card produces the correct on-screen message and logs the event," and "end-of-day totals reconcile to the transaction ledger with zero discrepancy." The Acceptance Test is the day those criteria are exercised, one by one, on the installed system in a staging station wired like a real one.
The team runs each scenario and marks it in a traceability matrix: criterion, test performed, result. Most pass. Three fail — reconciliation drifts by a few cents when a card is tapped twice in one second, and two error messages are wrong. Because the contract says all safety- and money-critical criteria must pass, the agency does not accept outright; it issues a conditional acceptance with a punch list, withholds the final payment milestone, and re-tests only the three failed items after the vendor's fix. When those pass, the system is accepted and the agency takes ownership. The verdict was never a matter of taste — it was whether each agreed criterion, traced to a recorded result, came back green.
How it works¶
- Freeze the criteria first. Acceptance criteria are negotiated and signed before or early in the build, so the target cannot drift to match whatever was delivered.
- One test per criterion. Each criterion is written to be objectively checkable — a concrete scenario with an unambiguous expected result — and paired with exactly one demonstration.
- Exercise and record. The deliverable is run against every scenario in a realistic environment; each result is entered in a criterion-to-result traceability matrix.
- Apply the acceptance rule. Typically all critical criteria must pass (with an agreed defect budget for cosmetic items), yielding accept, reject, or accept-with-conditions (a punch list re-tested before final sign-off).
Tuning parameters¶
- Criticality tiers / defect budget — which criteria are must-pass versus tolerable-as-punch-list. Tighter tiers protect the buyer but can stall handover over trivia.
- Scenario coverage — exhaustive enumeration versus a sampled subset. More coverage catches more, but each scenario costs time to script and run.
- Environment fidelity — a lab rig versus a production-like installation. Higher fidelity surfaces integration faults but is slower and costlier to stand up.
- Witnessing — self-attested by the vendor versus jointly witnessed by the buyer. Joint witnessing raises trust and dispute-resistance at the cost of scheduling.
- Conditional-acceptance policy — how severe a defect may be and still permit provisional acceptance against a punch list.
When it helps, and when it misleads¶
Its strength is that it makes handover objective and pre-committed: because the criteria were fixed in advance and each verdict traces to a recorded result, acceptance survives disputes and the deliverable cannot be redefined to pass. It is the natural fit wherever a contract, a "definition of done,"[1] or a regulatory handover needs an evidence-backed yes.
Its central failure mode is the proxy trap: the system passes every criterion yet is unfit in real use, because the criteria captured the happy path and missed the conditions that actually matter. Acceptance criteria written for convenience — easy to test, easy to pass — certify the test suite, not the deliverable. The classic misuse is treating a green matrix as proof of quality when the criteria never exercised load, edge cases, or adversarial input. The guarding discipline is to derive criteria from real operating conditions, deliberately include negative and boundary scenarios, and treat any criterion that "always passes" as a candidate for being too weak to matter.
How it implements the components¶
outcome_standard— the signed acceptance-criteria list is the standard: it states exactly what "accepted" requires.endpoint_evidence— the deliverable's observed behavior when exercised against each scenario (test runs, demonstrations, reconciled logs).evidence_alignment_map— the traceability matrix pairs every criterion with the specific result that satisfies or fails it, so nothing is accepted on impression.certification_decision— the formal accept / reject / accept-with-conditions act that transfers the deliverable.
It does not aggregate many heterogeneous launch signals or weigh who will rely downstream (accountability_use_context) — that holistic go/no-go is Readiness Review; nor does it convene an independent_reviewer_or_panel (that's Capstone Demonstration) or attach an expiry_or_renewal_rule to the result (that's Certification Record).
Related¶
- Instantiates: Summative Certification — Acceptance Test is the deliverable-and-product form of endpoint certification.
- Sibling mechanisms: Capstone Demonstration · Certification Record · Competency Signoff · Final Exam · Portfolio Review · Practical Checkout · Readiness Review · Rubric Review · Standardized Credentialing Exam
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: The deliverable is actively exercised in realistic scenarios, one per frozen criterion, to generate criterion-level pass or fail evidence before acceptance, so the operative form is an evidence-generating test.
Nearest alternative: Assessment, Review & Assurance — Certification is the downstream disposition; the mechanism first creates the evidence by running the delivered system through deliberate trials rather than only reviewing evidence already in hand.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Formal system acceptance against pre-negotiated requirements at commissioning or handover is a characteristic systems-engineering and procurement practice.
Related originating lineages:
- Computer Science & Software Engineering — Software and system testing developed executable user-acceptance suites and traceability from criterion to test result.
- Law & Governance — The binding accept-reject decision, conditional acceptance, punch list, and transfer or payment consequences derive from contractual governance.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Acceptance Test is deliberately narrow: it certifies this deliverable against these criteria, and says nothing about whether the wider launch is safe or the organization is ready to operate the thing. That broader judgment is Readiness Review, which may take a passed acceptance test as just one of many inputs.
References¶
[1] Schwaber, Ken, and Jeff Sutherland. The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Scrum Guides, 2020. Defines the Definition of Done as a formal quality state that makes completed work transparent. registry ↩