Learn Automation with MINATA #79: FAT and SAT — Turning a Checklist Into Evidence

FAT and SAT: Turning a Checklist Into Evidence

Works acceptance and site acceptance are not two occasions of switching the machine on to see whether it runs. They are a traceable chain from the requirement to the result and to whatever remains open. Done properly, they give the customer and the builder the same objective evidence that the machine meets what was asked of it.

Works acceptance starts from a frozen requirement

The works test should start from the user requirement, the functional specification, the I/O list, the safety concept, the drawings and a frozen software version. Testing against a version that is still changing produces results that mean nothing. Each test needs a precondition, the action, the expected result, the actual result, the evidence, the witness and a pass or fail status.

Traceability from requirement to result

Every important requirement should map to at least one test that demonstrates it. At acceptance, both parties can then read "this requirement is demonstrated by that test, with this result", instead of arguing from impressions. Anything not yet achieved goes onto a punch list, with an owner and a way forward.

Site acceptance tests the site conditions

Site acceptance confirms the same things under real conditions: utilities such as power and air, the layout, real material, the interfaces upstream and downstream, the operators' workflow and the environment. Do not simply carry the works checklist over and skip the risks that only appear once the machine is really installed — noise from neighbouring equipment, or real material that behaves differently from the test samples.

A worked engineering situation

A machine goes through works acceptance with a frozen software version, each function tested with evidence and a witness; a few items go onto the punch list. On site, acceptance repeats the tests that depend on real conditions — supply, material, the machines before and after — and closes the punch list. The acceptance file becomes evidence, not a sheet signed to get it over with.

The test scope, the criteria and the evidence all follow the contract, the requirements and the applicable standards.

Common mistakes

Testing against software or drawings that are not frozen.
Tests with no expected result and no evidence.
No mapping from requirement to test, so acceptance rests on impressions.
Carrying the works checklist to site unchanged, missing the site risks.
No punch list, or one with no owner.

Acceptance checklist

[ ] Works acceptance starts from frozen requirements and versions.
[ ] Each test has precondition, expected, actual, evidence and a witness.
[ ] Requirements map to the tests that demonstrate them.
[ ] Site acceptance covers utilities, material, interfaces and environment.
[ ] Open items sit on a punch list with an owner and a resolution.

Acceptance backed by evidence makes both the sign-off and the handover unambiguous. #80 closes the series with the handover of an automation system.

Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation

Previous — #78: Remote access for maintenance: https://minatavn.com/en/blog/automation-78-remote-access-maintenance

Next — #80: Handing over an automation system: https://minatavn.com/en/blog/automation-80-system-handover

View all MINATA technical articles