Test Program Verification and Defect Escape Control

A test program is a piece of software that decides whether a board is good, and like any other software it can be wrong in ways that do not announce themselves. A program that misses a net, applies a limit too generously or skips a step will pass every board it sees, including the ones that should be rejected.

Verification is the discipline that keeps that from happening. It covers the program itself, the fixture that applies it and the limits it uses, and it produces evidence that the test still performs the function it was written for.

What a Test Program Assumes

Every program rests on assumptions: that the fixture probes the pads it was designed for, that the components are within their tolerances, and that the limits match the design intent. When any of those changes, the program continues to run but stops being a valid test.

The most common failure is silent. A probe that no longer makes contact produces a measurement that is still inside the limit, so the board passes without being tested at all, and the fixture maintenance record is where that condition is normally found. Test coverage is therefore a claim that has to be demonstrated with a board carrying intentional faults, not an assumption that follows from a correct netlist.

Coverage Review Before Release

Coverage is reviewed by comparing the netlist and the bill of materials against the steps in the program, and by recording which nodes are tested, which are only powered and which are not touched. The gaps are what matter.

A program that covers 95 percent of the nets may still leave a power rail or a reset line untested, and those are exactly the nets whose failure is found by the customer. The review should be documented as a list of gaps with the reason for each one, rather than as a single percentage.

Fixture Correlation and Golden Boards

Correlation proves that the fixture and the program agree with a known good board. A golden board with deliberately introduced faults, often called a known bad board, is the stronger evidence, because it shows that the program detects what it claims to detect.

A practical set contains one good board, one board with an open, one with a short and one with a wrong value. Running the set at the start of a production run confirms that the whole chain, from the in-circuit and functional test stage to the fixture, is still capable of detecting a fault. The set should include a board with a shifted component, one with an open joint and one with a short, so that the program is asked the questions it will face in production.

Escape Analysis and Root Cause

A defect escape is a board that failed in the field but passed test. Each escape should be analysed by asking whether the fault was detectable in principle, whether the program attempted to detect it, and whether the detection failed because of a limit, a probe or a step that was skipped.

The answers separate a coverage gap from a hardware problem. Where the fault was detectable but not detected, the program needs a change; where the fault was never detectable in circuit, the answer is a different test stage, and the escape rate record for the optical stage should be reviewed at the same time.

Revision Control for Programs

A test program is a controlled document, and it should be released, versioned and archived in the same way as the assembly drawing. A program that exists only on the test station is a program that cannot be reproduced after the station is rebuilt.

The revision should be visible at the station, on the screen or on a label, so that the operator and the engineer are discussing the same version. Where a program is edited directly at the machine, the edit should be exported to the controlled copy before the shift ends, or the two will diverge within a week.

Verification After Any Change

Any change to the test program, the fixture, the board revision or the test limits invalidates the previous verification. The re-verification should be scoped to the change, but it should not be skipped on the grounds that the change was small.

A board revision is the change most often overlooked. Moving a test point or altering a component value alters the expected result, and a program that still runs without error may now be testing a different net from the one it reports. Moving a connector or rotating a part changes which probe reaches which net, so the fixture drawing has to be re-checked against the new revision before the program is released.

Limits, Guards and False Calls

Limits that are too tight produce false calls, and false calls lead to operators retesting boards until they pass. That behaviour converts a test into a lottery, and it is the main reason a station with poor limits has a lower escape rate in its records than in reality.

Limits that are too wide have the opposite effect and are harder to detect, because they produce no complaints. Reviewing the distribution of measured values against the limits, rather than only counting the failures, shows whether the guard bands are still meaningful, and the comparing of inspection methods at the same stage shows where the gaps sit. Wide limits let marginal assemblies pass, and the pass is only discovered when the product fails at functional test or in the field.

Evidence for the Customer

Customers increasingly ask for evidence that a test stage is verified rather than simply in use. The evidence is a package, not a statement: the coverage list with its gaps, the golden board results, the program revision history and the fixture maintenance record.

Assembling that package once makes every later audit cheaper. Where the evidence has to be reconstructed each time, the gaps in the record tend to be filled by description, and a description is not evidence of anything.

Records and Periodic Re-Verification

Periodic re-verification is a scheduled event rather than a reaction. The interval should be set by the product criticality and by how often the fixture is used, with a shorter interval for a station that runs several products on the same fixture.

The record for each event should name the program revision, the fixture condition, the golden board result and the person who performed the check. With that history, a change in escape rate can be connected to a specific verification event rather than to a general suspicion. Each event should be traceable to a program revision, a fixture condition and a board revision, so that a later escape can be explained rather than argued about.

FAQ

How is a test program verified? By reviewing coverage against the netlist, correlating the fixture with known good and known bad boards, and recording the program revision, the limits and the fixture condition in a verification package.

What is a golden board and why is it needed? A board with known faults that the program must detect, used to prove at the start of a run that the fixture and the program can still catch the defects the product is exposed to.

When should a test program be re-verified? After any change to the program, the fixture, the board revision or the test limits, and on a schedule set by the criticality of the product and the intensity of use.