Designing for production test

A prototype is tested by the engineer who designed it, with a bench full of instruments and as much time as it takes. A production unit is tested by an operator who did not design it, on a fixture, in the time the line allows. If the board was not designed with that second situation in mind, the factory ends up testing less than it should, more slowly than it should, or both.

This article covers what to build into the board, the firmware, and the process so that every unit can be tested quickly and the result can be trusted. Where production test fits among the build stages is covered in From prototype to production: EVT, DVT, and PVT explained, and the test specification the factory needs is part of What a complete manufacturing package includes.

What production test is for

Design validation asks whether the design is right. Production test asks a narrower question: was this unit built correctly? It assumes the design works and looks for assembly and part defects: solder shorts and opens, missing or wrong parts, parts placed backwards, damaged components, and boards that were never programmed or were programmed with the wrong image.

So production test does not need to characterize the product or prove margin. It needs to exercise every part of the board enough to catch a build defect, quickly, repeatably, and without judgment. A test that needs an engineer to interpret a scope trace is a design validation test, not a production test.

Choosing a test strategy

There are a few common approaches, and most products use more than one.

In-circuit test (ICT) on a bed-of-nails fixture. Spring-loaded pins contact test points across the board and check for shorts, opens, and part values. It is fast per unit, but the fixture is custom to the board and must be reworked when the layout changes. It suits stable designs at higher volumes.
Flying probe. Moving probes touch test points one at a time, so no custom fixture is needed. It is slower per board but suits small runs and designs that are still changing.
Functional test. The board is powered and run, usually with test firmware, and checked through its real interfaces: rails within limits, sensors reading sensible values, radios transmitting, buttons and LEDs working. It catches what structural tests miss, and it is usually the core of production test for a small team.
Boundary scan (JTAG). If the main processor and other parts support it, boundary scan can check connections between pins without physical access to every net. It helps on dense boards with BGA parts, where test points are hard to place.
Combined programming and test. At low volume, a single fixture often programs the board, runs a functional test, and records the result in one step. For a first production run, this is frequently the most practical choice.

For a small team at modest volume, a common pattern is automated optical inspection at the assembler, then a combined programming and functional test fixture, with flying probe or ICT added if the defects it would catch show up in practice. Ask your contract manufacturer what they already have and what they recommend for your volume; their existing equipment often settles the question.

Spring-loaded pins in the fixture press up on test pads on the underside of the board, so every test point must be on a pad the pins can reach. Schematic, not to scale.

Design the board for the fixture

Most of what makes production test easy is decided in layout. Plan for it before the layout is released.

Test points with real access. Put test pads on power rails, key signals, and every interface the test needs to reach, on one side of the board if possible so the fixture only needs pins from one side. Keep them clear of tall parts.
Programming access the fixture can use. A pogo-pin footprint or a set of pads works better on the line than a header someone has to plug a cable into. Bring out reset and boot-mode control so the fixture can recover a board that will not start.
Power the fixture can control. Let the fixture supply power through a defined point, and make it possible to measure current. A board that draws the wrong current at power-up is one of the quickest defects to catch.
A debug or log port. A UART reachable from the fixture gives the test a way to talk to the firmware and gives a technician a way to see why a unit failed.
Alignment features. Tooling holes and fiducials let the fixture locate the board accurately, so pins land on pads every time.
Access for the panel or the enclosure. Decide whether test happens on the panel, on the single board, or on the finished product, and make sure the needed pads are reachable at that point.

Test access built into the layout: pads for the fixture on one side of the board, features that locate the board, and room around tall parts. Schematic, not a real layout.

A design review should check all of this; a test pad costs almost nothing before layout is finished.

Give the firmware a test mode

The simplest approach is a manufacturing mode in the product firmware, entered through a pin, a command on the UART, or a condition the fixture can set. In that mode, the firmware answers simple commands from the test station: report the firmware version, read a sensor, drive an output, measure a rail through the processor’s ADC, transmit on a radio channel, run a self-test and report the result. Responses should be plain and machine-readable so the test software can parse them without guessing.

The alternative is separate test firmware that is loaded first, run, and then replaced with the product image. That keeps test code out of the shipping product but adds a programming step. Either way, decide how the test mode is locked or removed in shipped units, especially if it can read keys or change settings.

Serial numbers, calibration, and provisioning

The production test station is usually where each unit gets its identity. Plan for:

A serial number, written to the device and printed on the label, so the record and the physical unit match.
Calibration data, if the product needs it, measured on the fixture and stored on the device in a place a firmware update will not overwrite.
MAC addresses and radio identifiers, from a block you own or that came with the radio or module.
Keys and credentials, if the product has them, injected through a process that keeps them secret. This often needs its own tooling and controls; see Designing connected products for EU and UK cybersecurity rules.

Each of these should be read back after it is written and checked before the unit passes.

Radio products

A factory can confirm that a radio was built correctly: that it transmits on the expected channels, at roughly the expected power and frequency, and that it receives. It cannot practically repeat certification testing on every unit, and it should not try.

For a chip-down radio, a conducted test point or a footprint for an RF connector or switch lets the fixture measure the transmitter directly, which is more repeatable than measuring over the air. For a radio module, the module maker has usually tested the RF section; the factory test can focus on whether the module was soldered correctly and talks to the host. Over-the-air checks in a shielded box suit finished products, with limits that allow for placement variation.

Limits, logging, and traceability

A test is only as good as its limits. Set them from measurements on real units, not just from datasheets: wide enough to pass good boards from normal part variation, tight enough to catch the defects you care about. Review them after the first builds.

Log every result for every unit, not just pass or fail: the measured values, the firmware version, the fixture, the test software version, and the time. When yield drops or a unit comes back from the field, those records are how you find out why. Agree with the contract manufacturer on where the logs live and how you get them.

Fixture cost, lead time, and ownership

A bed-of-nails fixture is designed and built after the layout is final, so a late layout change delays it. Ask for quotes and lead times early.

Settle who owns what. Some contract manufacturers design and build the fixture, some build to your design, and some expect you to supply it. Make sure you own, or at least have a copy of, the fixture design and the test software, so you can move production or fix the test without starting over.

Keep test time short

Test time is line time, and on a small run the test station is often the slowest step. Run checks in parallel where possible, avoid fixed delays in favor of waiting for a ready signal, and program at the fastest reliable speed. Watch what fails in practice and drop or shorten tests that never catch anything, as long as something else still covers that part of the board.

A short checklist

Before the build where the fixture is designed:

Test strategy agreed with the contract manufacturer.
Test pads on rails, key signals, and interfaces, reachable from one side.
Programming, reset, and boot control reachable by the fixture.
Fixture-controlled power with a way to measure current.
Firmware test mode or test image, and how it is disabled in shipping units.
Serial number, calibration, and provisioning steps defined, with read-back.
Conducted RF access on chip-down radio designs.
Limits, logging, and record retention agreed.
Fixture and test software ownership settled, with copies in your hands.

If you are heading toward a first production build and want help planning the test, get in touch.