Replace an undefined request for a “tested board” with a controlled procedure, coverage description, required equipment and recorded acceptance criteria.
Describe what the test must establish
Start with the product requirements that matter for release. Separate assembly observations, connectivity checks, programming verification and functional behavior. These activities can complement one another, but their names do not guarantee identical coverage.
State which functions are included, which are excluded and why. A board that powers up successfully may still have an untested interface or a failure that appears only under a defined load. The acceptance record should make those boundaries understandable.
Write the test setup as part of the procedure
- Board revision, assembly variant and firmware configuration.
- Equipment, fixtures, cables and connection instructions.
- Supply and load conditions appropriate to the intended test.
- Measurement points, sequence and acceptance limits.
- Required result fields and the unit identifier recorded with them.
Use diagrams or photographs where they make fixture connections unambiguous. A procedure that depends on one engineer remembering the cable orientation is not a reproducible handoff.
Make pass criteria observable
Replace statements such as “check communication” with the defined exchange, response and acceptable outcome. Replace “check power” with the intended operating condition, measurement and limit. The limit must come from the product’s requirements and design review, not from an arbitrary default copied from another board.
For example, testing an interface with one loopback cable may exercise a different path from testing it against an external device. Record the actual arrangement so the result is interpreted correctly.
Define failure handling
State what happens when a step fails: stop the sequence, capture the failure information, quarantine the unit or follow an approved diagnostic procedure. Decide who can authorize rework and which tests must be repeated afterwards.
Keep a retest result linked to the earlier failure rather than erasing it. This makes recurring problems easier to recognize and prevents a final pass status from concealing a process issue.
Validate the handoff on a representative build
Have the intended operator follow the procedure with the specified fixture and record any ambiguities. Review test time and coverage before committing to a larger run. If the design or firmware changes, assess whether the procedure and acceptance limits remain applicable.
The testing overview can organize the discussion, while the project inquiry form can capture the requested test scope for an assembly review.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist