Functional Test Coverage Control for PCBA Builds: 6 Rules

A functional test powers an assembly and checks that it behaves as the design intended. It is the closest thing to the customer experience that exists inside the factory, because it exercises the product rather than the individual nets.

Its weakness is that it only proves what it exercises. A unit that passes can still fail in the field if the test never applies the condition that matters, which is why coverage is the first question to ask of any functional test specification.

<img src="https://www.gopcba.com/wp-content/uploads/2024/09/Standard-PCB.jpg" alt="Functional test fixture holding a printed circuit board assembly” />

What Functional Test Proves

The test proves that the assembly works under the conditions applied, with the firmware installed and the interfaces connected. It is a system level check that can catch a fault which in-circuit test cannot see, such as a wrong component value that still measures within the net tolerance.

What it does not prove is that the design is correct, that the margins are adequate or that the unit will work outside the tested conditions. Those are design and qualification questions, and confusing them with production test is how a weak design reaches the field.

Coverage and the Test Specification

Coverage is the list of functions, interfaces and conditions the test exercises, written down and reviewed against the design. Each item is traced to a test step, and the steps that were deliberately left out are recorded with the reason. The pass criteria for each step are written as a measured value or a defined behaviour, because a criterion that says acceptable cannot be repeated by another operator, another fixture or another shift.

The specification also states the conditions, including the supply voltage limits, the temperature, the load and the timing. A test that is run at nominal voltage only will not find a unit that fails at the low end of the supply range, however thorough the rest of the sequence is. The same argument applies to the load, the timing and the interfaces, so the conditions are listed in the specification rather than left to the judgement of the test operator.

Fixture Design and Contact

The fixture has to make reliable contact with every point the test needs, and that contact has to survive thousands of insertions. Pogo pins, edge connectors and cable harnesses each have a different wear behaviour, and the wear shows up first as an intermittent failure. Contact life is tracked by insertion count, and the fixture is rebuilt or re-pinned when the count reaches the value at which contact resistance begins to rise.

Contact resistance also matters, because a test that measures a voltage through a worn pin can fail a good unit or pass a marginal one. The fixture is verified with a known good and a known bad unit at a defined interval. The related mechanical requirement is described in the coplanarity notes.

Limits, Margins and Guard Bands

A limit that sits exactly at the design value will pass and fail units that are functionally identical, because measurement variation is larger than the difference between them. The limit is therefore set with a guard band that accounts for the fixture and the instrument.

Guard bands are chosen from measurement repeatability rather than from convenience. Where the measurement varies by more than the guard band, the test is measuring itself, and the fix is a better fixture or a better instrument rather than a wider limit. The guard band is recorded with the limit so that a later reviewer can see how much of the margin belongs to the design and how much belongs to the measurement.

Handling Units That Fail

A failed unit is an opportunity to learn something, provided the failure is recorded in enough detail to be reproduced. The test step, the measured value and the limit are written down, and the unit is kept until the cause is understood.

Retest without diagnosis is the commonest way to lose that information. A unit that passes on the second attempt has not been repaired, and the failure is likely to reappear at the customer, which is why the retest rate is measured rather than ignored. A rising retest rate is treated as a signal that something in the process has changed, even when every unit eventually ships and the yield figure looks healthy. The retest is logged with a failure code so that the pattern can be reviewed weekly rather than after a customer complaint, and the code is what makes the review useful.

Test Time and Throughput

Test time is a cost, and the pressure to reduce it usually falls on the steps that take longest. The steps that can be shortened safely are the ones with generous margin, while the marginal ones are exactly the steps that justify the test.

Parallel testing and better fixturing reduce time without losing coverage, while deleting a step reduces coverage permanently. The coverage list is what prevents a throughput improvement from quietly removing a check that was protecting the product.

Records and Traceability

Each unit is identified in the record with its serial number, the test program revision, the fixture and the operator. The measured values are stored rather than only the pass or fail result, because the values are what allow a trend to be seen before a limit is crossed. Storing values rather than results is what turns a production test into a process monitor instead of a gate that only reports pass or fail.

The records also support a field return investigation. A unit that failed in service can be compared with its original test data, and a marginal value that passed at the time becomes visible. The wider release checks are listed in the design release notes.

Change Control

A change to the firmware, the fixture, the test program or a component is a change to the test, and the coverage list is reviewed with it. A program revision that is not accompanied by a coverage review can lose a step without anyone noticing.

Where the change affects a measured value, the limits are re-verified with known good units before the revision is released to production. Missing part and value errors that escape the placement stage are usually caught here, which is the argument for keeping the test broad.

FAQ

Is functional test a replacement for in-circuit test? No. In-circuit test checks the individual nets and components, while functional test checks the assembled behaviour. Each finds faults the other misses, and the coverage of the two is usually reviewed together. Where the two overlap, the duplication is deliberate, because a redundant check on a critical net costs far less than a single field return from a customer.

How much coverage is enough? Enough to detect every failure mode that the process is known to produce, plus the modes the design analysis predicts. The list is justified item by item rather than set as a percentage. A percentage figure hides the fact that the part left uncovered may be the one function the customer actually uses, which is why the list is reviewed function by function.

Why do units fail in the field after passing the test? Usually because the failure needs a condition the test does not apply, such as a temperature extreme, a supply transient or an intermittent connection. Those conditions are added to the coverage list when a return is analysed. The list is updated with the new condition, and the test specification is re-released with the coverage item recorded against it.