Your prototype powers on. The sensors return data, the app connects, and the enclosure fits. Then your manufacturing partner asks: how will we verify every unit before it ships?
If the answer involves an engineer, an oscilloscope and several manual steps, the product still needs work. The person who designed the board may know where to probe and how to recognize a suspicious signal. A production operator needs a repeatable procedure with clear acceptance criteria.
Design for test, or DFT, makes that procedure possible. It connects PCB layout, firmware behavior and manufacturing requirements so a unit can be checked without improvising. For a startup moving from a handful of prototypes to its first pilot build, this is worth planning before the next board revision.
Start with the failures you need to catch
Ask what could be wrong with an assembled unit and how you would detect it. A device that boots might still have a disconnected sensor, a damaged input, excessive standby current or an antenna connection problem.
List the important product functions and likely assembly faults. Map each one to a measurement or controlled check. Keep design validation separate: testing selected prototypes across operating conditions answers different questions from checking each manufactured unit for assembly defects.
- Power: verify operation and current consumption in defined states.
- Interfaces: check communication with required sensors, memory and peripherals.
- Inputs and outputs: apply a known input and measure the response.
- Connectivity: complete the intended connection or communication check.
- Identity: verify the serial number, firmware version and configuration.
This coverage map helps decide what belongs in board-level testing, what needs an assembled-product check, and what requires specialist equipment.
Reserve physical access before routing the PCB
A signal can be easy to inspect on a schematic and difficult to reach on the assembled board. Components, batteries, shields and enclosure walls may block the probe. Test access therefore belongs in the layout and mechanical review.
Review power rails, ground connections, programming interfaces and critical signals with the manufacturer or fixture designer. Agree accessible pad locations, clearances, alignment features and board support. There is no universal pad size or spacing that suits every fixture.
Keysight identifies test-point density, pad size and component spacing as factors affecting achievable in-circuit test coverage in its in-circuit test overview. Involve the test team while the board can still change.
Do not add pads indiscriminately to sensitive signals. Consider the electrical effect of the access point and measurement method, especially around RF and fast interfaces. Testability is a design tradeoff, not a request to expose every net.
Give firmware a defined role in the test
Factory software should be able to ask the device for an unambiguous result. Useful commands may identify the board revision, report a sensor reading, exercise an output, enter a defined power state or return a diagnostic code.
Decide how these commands are accessed, which firmware image runs the test and how the unit enters its shipping configuration. If you use a separate factory image, document and verify the transition to production firmware. If diagnostics are included in production firmware, define the access controls and permitted behavior.
Programming, calibration and testing need an agreed sequence. A pass result from an earlier stage should not silently stand in for a check after firmware or configuration changes. Record which software produced the result.
This is why PCB and firmware development benefit from a shared scope. The board needs the access that the firmware and station will actually use.
Choose the test method for the build
Inspection, electrical checks and functional tests reveal different problems. Choose the combination around product risks, available equipment, expected volume and the cost of a missed defect.
- Visual or automated optical inspection: checks visible assembly features and can identify certain placement or soldering issues.
- In-circuit or flying-probe testing: checks accessible electrical characteristics according to the equipment, board design and test program.
- Functional testing: powers the assembly and evaluates selected behavior through defined inputs, outputs and measurements.
- Final assembly testing: checks functions that depend on the finished product, such as connectors, controls or integrated sensors.
A small pilot may use a guided bench setup. A larger build may justify a dedicated fixture and automated sequence. Neither should depend on an undocumented judgment call. NI's electronics functional test overview describes automated test systems used in manufacturing.
Set limits from requirements and measurement evidence
One working prototype does not define an acceptance range. Start with the product requirement, then account for component variation, operating conditions, instrument uncertainty and fixture repeatability.
For example, a battery-powered product needs its current measurement tied to a defined state. A reading immediately after boot may not describe sleep behavior. Specify supply conditions, the state transition and when the measurement is taken.
Separate an electrical failure from a station problem. Poor probe contact should produce a diagnosable result, not an invitation to keep testing until the board passes. Define when retesting is allowed, how it is recorded and when a unit goes to engineering review.
Keep results connected to the unit
A pass indicator is useful on the line. A saved record is useful when a batch starts failing or a returned unit needs investigation. Use a unique unit identifier and retain the context needed to interpret the measurements.
- Unit identifier and hardware revision.
- Firmware, configuration and test-sequence versions.
- Station identifier and test timestamp.
- Measured values, acceptance limits and result codes.
- Retest or rework history where applicable.
Match the record format and retention process to product and customer requirements. Start with a system the team can maintain, and make sure records can be retrieved when needed.
Use the pilot to validate the test process
The pilot is a chance to learn about the station as well as the product. Can an operator load the unit consistently? Are contacts reliable? Does the sequence distinguish a device fault from a setup error? Are repeated measurements consistent?
Where practical, use safely prepared samples with known faults to challenge the relevant checks. Repeated passes on working boards demonstrate repeatability, but do not prove that the station detects the defects you planned for.
Review failures and cycle time together. A slow measurement may deserve automation; an unreliable contact may deserve a fixture change. Make these decisions from pilot evidence before committing to a larger run.
A checklist before the next PCB release
- Map important functions and likely faults to explicit checks.
- Review test access with the PCB, mechanical and fixture teams.
- Define programming, diagnostics, calibration and shipping configuration.
- Document test conditions, limits and permitted retests.
- Connect measured results to each unit and software version.
- Plan a pilot review of fault detection, repeatability and throughput.
At CoBuild Labs in T. Nagar, Chennai, our electrical engineering, firmware and manufacturing support workstreams help product teams plan these interfaces before production handoff. Deliverables and testing responsibilities are agreed for the project.
If your next milestone is a pilot build, share your current board revision and manufacturing plan. A testability review can identify the access, diagnostics and documentation that belong in the next design release.