FAT vs SAT: what is the difference and why both matter?
Factory Acceptance Testing and Site Acceptance Testing are often treated as separate documents owned by different teams. In reality, they are two checkpoints in the same delivery story. FAT establishes that a system is ready to leave the factory or integration environment. SAT proves that the delivered system performs as required after installation at site. The most effective teams connect both stages to the same system record so evidence, failures, remediation and approvals remain traceable from build through sign-off.
What Factory Acceptance Testing is meant to prove
Factory Acceptance Testing is normally performed before equipment or a complete system is released for shipment or site deployment. The purpose is not simply to demonstrate that equipment powers on. A useful FAT proves that the agreed configuration has been assembled, critical functions operate as expected, known defects are visible, and the customer or internal approver has enough evidence to authorize the next stage of delivery.
- Verify equipment identity, configuration and serial-number records.
- Confirm functional requirements that can be tested before site installation.
- Record measurements, screenshots, photos and other supporting evidence.
- Capture failures as controlled issues rather than handwritten exceptions.
- Document who reviewed the results and whether release was approved.
What Site Acceptance Testing is meant to prove
Site Acceptance Testing happens after the system reaches its operational environment. That changes the test context. The team is no longer validating only the assembled system; it is validating the system as installed, connected and operating with site-specific infrastructure, communications, power, interfaces and environmental conditions.
A SAT result therefore has more value when the reviewer can see the history that led to it. If a component passed FAT but later fails at site, the team should be able to see the earlier result, the new failure, the issue that was opened, the corrective work and the subsequent retest without searching several folders.
FAT and SAT compared
| Area | FAT | SAT |
|---|---|---|
| Primary objective | Verify readiness before shipment or deployment | Verify performance after installation at site |
| Environment | Factory, lab or integration facility | Customer or operational site |
| Typical focus | Configuration, functions, interfaces and build quality | Installed performance, site integration and operational readiness |
| Failures | Resolve before release or document controlled exceptions | Create site issues, remediate and retest |
| Approval | Release for shipment or next delivery stage | Readiness for acceptance, commissioning completion or handover |
The exact scope varies by project, but the distinction is less important than the continuity between stages. A system should not appear to become a new object simply because it moved from the factory to the site. The identity of the system, its equipment, evidence and unresolved exceptions should carry forward.
Where commissioning fits
Commissioning is often broader than SAT. SAT confirms requirements at site, while commissioning establishes that the complete installed solution is ready to operate in its intended environment. Commissioning may include configuration checks, dependencies, operational procedures, interfaces, performance observations and final readiness activities that are not represented by a single SAT procedure.
- Factory readiness
Complete FAT against the agreed factory or integration criteria.
- Site installation
Record the actual system, equipment and installation context at site.
- Site verification
Execute SAT and capture failures, evidence and retest results.
- Commissioning readiness
Confirm the complete operational environment and any remaining dependencies.
- Acceptance and handover
Present a controlled record for customer approval and project closeout.
What should happen when a test fails
A failed test should not become an isolated note in a spreadsheet. It should create a traceable path from the failed requirement to an owned issue. The issue should preserve the original test context, identify who is responsible, describe the corrective action and remain open until the affected requirement has been retested.
How Valtoroq connects the stages
Valtoroq is built around a single operational record for the delivered system. FAT, SAT and commissioning tests can be separated into their own test libraries and procedures while still remaining connected to the same project, site and system. A failure can create an issue without losing the test context, and the reviewer can see the evidence, remediation and approval history before sign-off.
- Reusable FAT, SAT and commissioning templates.
- Test runs tied to the system being delivered.
- Pass/fail results with evidence and comments.
- Issues linked directly to failed test context.
- Retest history instead of overwritten results.
- Approvals and acceptance based on the same operational record.
- Handover records built from work already completed during delivery.
A practical FAT and SAT checklist
| Stage | Record to keep |
|---|---|
| Preparation | Approved procedure, scope, system identity and prerequisites |
| Execution | Individual test results, evidence and operator details |
| Failure | Linked issue, description, owner and severity |
| Remediation | Corrective work, notes, attachments and status |
| Retest | New result tied back to the failed requirement |
| Approval | Reviewer, decision, date and any controlled exceptions |
| Acceptance | Final readiness, customer decision and remaining open items |
| Handover | Controlled documents and complete system history |
The objective is not to create more administration. It is to avoid rebuilding the delivery history at the point when the project is under the greatest pressure to close. When the operational record is maintained throughout delivery, FAT, SAT, commissioning and handover become connected stages rather than separate paperwork exercises.