Field Acceptance Test¶
Acceptance test — instantiates Operational Context Validation Testing
Runs the finished system in its real deployment environment and signs off each requirement as met or not-met, against acceptance criteria fixed before the test.
A Field Acceptance Test is the formal moment where a delivered system is put through its paces on site, in the environment it will actually run in, and each written requirement is checked off as met or not-met against tolerances that were fixed before anyone ran anything. Its defining idea is the pairing of two things a bench test cannot supply at once: the real operating context (the actual users, data, integrations, and physical conditions of the deployment site) and a contractual, per-requirement verdict. It is not a survey of how the system "feels" and not a judgment about whether to launch the whole program — it is a line-item pass/fail: requirement 14.3 either demonstrably holds here, in this building, on this hardware, or it does not, and the acceptance criteria written in advance say which.
Example¶
A regional airport has commissioned a new automated baggage-handling system for a rebuilt terminal. The vendor's factory tests all passed, but a factory is not the terminal: the real building has longer conveyor runs, the airport's own scanner network, live check-in feeds, and a mix of hard-side and oversized bags the factory never saw. Before the airport signs the handover, both parties run a Field Acceptance Test against a pre-agreed requirement list — sortation accuracy ≥ 99.5% on a representative bag mix, mishandled-bag rate below X, tote recirculation clears within N minutes at peak throughput, manual-encode fallback works when a tag is unreadable. They inject a known, tagged test-bag population through real check-in desks during a simulated peak, trace each requirement to what the system actually did, and record it. Two requirements fail: oversized bags jam a transfer at one junction, and the fallback encode station mis-routes under load. The verdict is not "the system is bad" — it is a precise, signed list of which clauses passed and which two block acceptance until fixed and re-tested.
How it works¶
What distinguishes a Field Acceptance Test from generic field trials is its requirement-anchored, adversarial-to-optimism structure:
- Freeze the criteria first. Acceptance thresholds, the test bag/data population, and the pass conditions are agreed and signed before the run, so a marginal result cannot be reinterpreted as a pass afterward.
- Run it in the real context, not a proxy. The test executes on the deployed hardware, at the real site, with the actual integrations and a representative load — the point is to catch exactly what the factory environment removed.
- Trace, don't summarize. Every requirement maps to an observable behavior with a recorded outcome; the deliverable is a filled-in trace matrix, not a narrative.
- Verdict is line-item. The output is a signed pass/fail per requirement plus a punch-list of failures to remediate and re-test, not a single go/no-go for the program.
Tuning parameters¶
- Requirement coverage vs. test cost — test every clause or a risk-weighted subset. Full coverage is defensible but slow and expensive; sampling is faster but leaves untested clauses as residual risk.
- Acceptance tolerance width — how much margin a requirement must clear to pass. Tight tolerances catch marginal builds but risk failing on measurement noise; loose ones pass more but accept weaker systems.
- Load and mix realism — how closely the injected population matches real peak conditions. Higher realism finds more, but a truly representative peak can be hard to stage safely on a live site.
- Witnessing and independence — self-run, customer-witnessed, or third-party-adjudicated. More independence buys credibility at the cost of scheduling and rigidity.
- Re-test scope on failure — re-run only the failed clause, or the whole suite (a failed fix can regress a passed requirement).
When it helps, and when it misleads¶
Its strength is decisiveness under real conditions: it converts "the vendor says it works" into a signed, context-grounded record that this system meets these requirements here, which is why it anchors commissioning and contractual handover. Its classic failure mode is teaching to the test — the system is tuned to pass the exact scripted acceptance run and quietly fails on the conditions the script left out, so a clean Field Acceptance Test can certify a narrow competence as if it were general fitness. This is the well-known gap between a Site Acceptance Test and true operational readiness.[n1] The guarding discipline is to keep the acceptance population representative and partly undisclosed, and to treat a pass as verification of the tested requirements only — never as evidence about behavior the test did not exercise.
How it implements the components¶
A Field Acceptance Test fills the verify-the-requirements-in-context slice of the archetype, and only that slice:
operational_context_model— the test is defined and executed against the real deployment site's users, data, integrations, and physical conditions, not a lab proxy.requirement_behavior_trace— its core artifact: each requirement mapped to an observed behavior with a recorded, signed pass/fail.acceptance_stop_and_escalation_criteria— the pre-frozen tolerances and pass conditions that make the verdict binding rather than interpretive.
It does not aggregate these verdicts into a rollout authorization, keep a running lab_to_field_delta_log across the campaign, or declare a context_transfer_boundary for where the decision applies — that program-level weighing and scoping is the Go/No-Go Review Gate's job.
Related¶
- Instantiates: Operational Context Validation Testing — supplies the signed, per-requirement field evidence the archetype's decisions depend on.
- Consumes: Production-Like Testbed — a testbed dry-run typically precedes the on-site acceptance run so most failures are caught before witnessing.
- Sibling mechanisms: Shadow-Mode Trial · Canary or Limited Rollout · Production-Like Testbed · Operational Scenario Rehearsal · Environmental Stress Run · Workflow Observation Log · Go/No-Go Review Gate
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Field Acceptance Test operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it runs the finished system in its real deployment environment and signs off each requirement as met or not-met, against acceptance criteria fixed before the test.
Independent corroboration: The frozen evidence defines Field Acceptance Test as 'Runs the finished system in its real deployment environment and signs off each requirement as met or not-met, against acceptance criteria fixed before the test', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Acceptance testing in the actual deployment environment arose in systems engineering and procurement practice.
Related originating lineages:
- Aviation & Aeronautics — Aerospace acquisition and airport-system commissioning materially institutionalized field acceptance testing.
- Computer Science & Software Engineering — Software and telecommunications engineering materially standardized field and user acceptance testing.
Review resolution: Both reviewers agree that engineering_design is primary. I retain computer_science, aviation_aeronautics only as formative origin lineage(s), without treating every later application as an origin. cross_disciplinary_synthesis is appropriate because the exact artifact combines contributions from multiple professional lineages. Reach is multi_domain as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is false because the artifact is already established enough that encyclopedia-specific synthesis is not required. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] In systems engineering, a Site Acceptance Test (SAT) verifies the installed system at the customer's site after a Factory Acceptance Test (FAT) passed at the vendor's — a formal recognition that passing in the factory does not certify behavior on site. The recurring pitfall is treating SAT success as proof of general operational readiness rather than of the specific clauses it exercised. ↩