Acceptance testing is the step in automation projects most often left to the last minute and the one that causes the most argument. Yet a well-prepared acceptance test is the closing evidence of a project in both technical and commercial terms: it puts in writing that the system works to specification, what was accepted and what remains open. This article explains the difference between the factory acceptance test (FAT) and the site acceptance test (SAT) and how to prepare for each.
FAT proves the system’s logic and graphics in a controlled setting; SAT confirms them with real instruments and process. They are not repeats of each other but complements.
The FAT and SAT flow
What does FAT prove?
In a factory acceptance test the system is set up at the vendor’s or integrator’s premises before it ships and is usually tested with simulated I/O. The aim is to prove that control logic, operator graphics, alarm and event structure, history and reports work to the functional specification. A defect found at FAT is solved at a desk in the factory; the same defect on site can cause a stop. The more thorough the FAT, the calmer the site phase.
The limits of FAT must also be written clearly: field cabling, real measurement ranges, valve and motor dynamics and the real behaviour of field devices cannot be proven at the factory. Such topics should be marked explicitly in the test plan as “to be verified at SAT”.
What does SAT prove?
The site acceptance test verifies that the system works at the plant where it is installed, with real instruments, valves and process. Loop checks (verifying each signal from the field device to the operator display), redundancy switch-over tests, communications and upper-system interfaces, and control performance in process conditions are proven at this stage. At the end of SAT the plant receives a signed acceptance certificate showing it can take the system into operation.
How to prepare the test plan
- Derive it from the specification. Every test should be tied to a requirement in the specification (a requirement–test traceability matrix).
- Write the acceptance criterion up front. Not “it should work correctly” but measurable statements such as “when input X reaches value Y, the output should reach this value within Z seconds”.
- Document the limits of simulation. List what is simulated at FAT and what cannot be; the second group moves into the SAT plan.
- Prepare test forms. Each step needs fields for expected result, actual result, date, tester and approver. Consistency improves when test forms are derived from the I/O list.
- Clarify roles and approval authority. Who tests, who approves, who closes an open item?
Managing open items
No test passes everything the first time; what matters is that findings are closed traceably. Keep a record for every finding: description, severity, owner, target date, resolution and re-test evidence. Splitting findings into three classes is common and practical:
| Class | Meaning | Effect on acceptance |
|---|---|---|
| A — Blocking | Directly affects safety or production | Acceptance not given until closed |
| B — Important | Affects function but has a workaround | Accepted with a dated closure plan |
| C — Minor | Cosmetic or improvement | Tracked in a list after handover |
State in the plan that after every software correction the tests affected by the change must be repeated; otherwise a fix may introduce a new defect. At closure, the approved final software revision should be part of the handover package (commissioning and handover documentation).
Documents to deliver
- Signed FAT and SAT reports and the requirement–test traceability matrix.
- The list of closed and still-open items.
- The final software revision and a configuration backup.
- The current I/O list, network diagram and as-built documents.
You can start preparing the test plan with the project preparation checklist. In DCS system installation and programming projects, ASP Otomasyon writes the FAT/SAT plan together with the specification and runs the test process with you.
Frequently asked questions
Can we skip FAT and test directly on site?
In theory yes, but it is expensive: logic and graphics errors are found on site, under pressure and with downtime risk. FAT catches them cheaply in a controlled setting.
Should the customer attend FAT?
Yes; when a customer representative attends, the acceptance decision is faster, expectations are clarified early and surprises on site are fewer.
Is a defect found at SAT a failure of FAT?
Not always. Field cabling and real process dynamics cannot be proven at FAT. What matters is that nothing provable at FAT is left to SAT.
