Factory Acceptance Testing for Custom Machines: A Practical FAT Checklist

The machine is assembled, the supplier invites you to a factory acceptance test, and everyone would like the day to end with a signature. A useful FAT makes that signature mean something. It connects the agreed requirements to a defined machine configuration, representative tests, recorded results, and a clear decision about anything that remains unresolved.

This guide is for buyers and engineering teams preparing a custom-machine FAT. It does not prescribe a universal standard or replace product-specific safety and compliance work. The scope should reflect your machine, contract, intended use, and responsible specialists. A workshop demonstration can be valuable, but applause is not a measurement method and a video is not automatically a complete test record.

1. Define the purpose and boundary of the FAT

State whether the event checks functional behavior, agreed performance, build quality, interfaces, documentation, or a particular combination. Identify the machine, quantity, configuration, and requirement revision. Also identify the conditions that cannot be represented at the supplier site. Some integration, utilities, environment, and operating checks may belong to site acceptance or commissioning after installation.

Keep factory acceptance, site acceptance, and wider validation connected but distinct. Passing one does not prove every requirement under every condition. NASA's verification and validation plan outline offers a useful structure for defining items, methods, and evidence. Apply proportionate traceability rather than copying a large-program document set into a small machine project.

If the original scope is unclear, resolve it before arranging the event. The machine RFQ guide explains why acceptance conditions belong in the purchasing brief. They are difficult to agree objectively after both parties have planned transport for tomorrow.

2. Build a requirement-to-evidence matrix

List the requirements in scope, their identifiers, verification methods, procedures, pass limits, and evidence locations. Some items are established by inspection or analysis; others need demonstration or testing. The method should fit the claim. A drawing review can establish a specified dimension on the release document; checking the manufactured feature may need a different record.

Define ambiguous terms before testing. Continuous operation, automatic recovery, easy changeover, and zero damage can mean different things to different people. Put the conditions and criteria in writing. The test plan should make it possible to disagree about a result using evidence, rather than disagree about what the requirement meant in the first place.

3. Confirm the machine and test setup are ready

Record mechanical, electrical, PCB, firmware, display, and configuration revisions relevant to the test. Identify temporary arrangements and substitutions. A test on a development assembly may answer useful questions without representing the delivered machine. State whether a later configuration change requires another review or retest before the result is accepted.

Check representative samples, utilities, connected equipment, tools, measurement arrangements, personnel, and the planned procedure. Confirm any instrument or reference checks appropriate to the measurements. Agree on how the test can be paused and who decides whether conditions remain valid. Preparation prevents the event becoming an improvised debugging session with visitors standing politely around the bench.

Machine and unit identity:
Requirements and procedure revisions:
Mechanical, electrical, software, and configuration baseline:
Representative input and expected output:
Utilities, interfaces, instruments, and references:
Temporary deviations and their approvals:
Responsible operator, witnesses, and reviewers:
Pass criteria and retained evidence:
Pause, issue-classification, and retest process:

4. Test the process the customer will actually use

Cover the intended material range, normal operating sequence, product selection, loading, unloading, replenishment, changeover, and relevant operating modes. Select cases from requirements and risk, not only the samples that behave most conveniently. Identify the limits of the sample set. A short run with one product can be informative without establishing performance across the complete range.

For a throughput check, agree on the measurement interval, start and finish events, accepted output, rejects, interruptions, and counting rules. The cycle-time guide explains why nominal cycle time is different from accepted output over a period. Preserve enough detail to understand why a rate was achieved or missed.

For user interaction, observe whether the operator can complete the defined task using the intended information and controls. Do not let the original designer's continuous verbal guidance conceal a missing instruction or unclear state. Record those findings as interface or documentation work, not as evidence that users need to become more intuitive.

5. Include defined faults and interrupted sequences

Plan relevant fault and interruption tests through an appropriate reviewed procedure. Examples may include missing input, incomplete movement, communication timeout, unavailable service, or an interrupted transaction. The setup and method must be appropriate to the equipment and responsibilities. Never improvise by bypassing a protective function to make a fault easier to reproduce.

For each case, define detection, machine state, output behavior, operator message, records, and permitted recovery. Confirm that recovery does not repeat an irreversible action or lose the information needed to resolve it. State-machine design provides a useful functional model, while control-system design explains the wider architecture.

6. Record results so another reviewer can interpret them

For each procedure, retain setup, configuration, steps, measurements or observations, pass limits, result, and reviewer information. Record failures when they happen. Do not replace the initial result with a clean pass after an adjustment. The correction and retest are part of the evidence and may explain a change needed in production instructions or another unit.

Distinguish a test deviation from a product failure. If the supplied sample or utility differs from the agreed condition, record that difference and decide whether the result is still usable. If the product does not meet the requirement, record the finding and disposition. Neither should disappear into a general note saying that the demonstration was broadly satisfactory.

7. Include handover and service checks

Review drawings, BOMs, software, configuration backups, operating instructions, maintenance information, test records, and agreed source files. Tie them to the tested configuration. An impressive FAT can still leave the customer unable to obtain a spare or restore the machine after a repair. Documentation should support the tasks that follow delivery.

Where appropriate, demonstrate a representative service or changeover task using the documented process. Record tools, access, parts, configuration, and verification. Maintainable machine design explains the design inputs, and the handover checklist provides the release-package checks. The FAT can expose missing information while the supplier team is still available.

8. Make the release decision explicit

Review completed evidence and every open item before deciding on shipment or acceptance. Identify conditions, responsibilities, retests, documentation updates, and any restrictions. The agreement should define who has authority to accept deviations. A transport booking should not silently become approval of unresolved engineering work.

If the machine changes after the test, assess what evidence remains valid. Replacing a sensor, modifying a mechanism, or changing firmware may affect more than the specific symptom being corrected. Keep the release configuration and test record aligned. For repeat builds, transfer lessons into the manufacturing and functional-test package rather than leaving them as annotations on one FAT sheet.

1. Confirm which requirement checks have valid results.
2. Review failures, deviations, and configuration changes.
3. Approve corrective work and the affected retest scope.
4. List site-dependent checks and their owners.
5. Verify required release documents and support arrangements.
6. Record the final decision and any explicit conditions.

9. Prepare a FAT plan while there is still time to improve it

Start the acceptance discussion during requirements and design reviews, not the week before shipment. This gives the team time to add test access, collect representative materials, prepare fixtures, and resolve disagreements about performance. A testable requirement is easier to engineer and easier to accept.

SolveMpire can discuss FAT planning alongside machine development and manufacturing support. Share the requirements, delivery configuration, available samples, site interfaces, and desired evidence. A useful plan should make the final review less dramatic because both parties already know what must be demonstrated.