Functional Test and Test Fixture Development for PCBA

An assembly that has been built correctly does not necessarily work, and a product that works does not necessarily work within its specification. The functional test is the stage that answers the second question, and it is the last opportunity to prevent a fault from reaching a customer. Its design is a project in itself, because a test is only as good as the coverage it provides and the fixture it depends on, and both of those are decided long before the product is in production.

Defining Test Coverage Before the Fixture

The first task is to decide what has to be verified. The supply rails and their tolerances, the reset and clock behaviour, the communication interfaces, the analog measurements, the indicators, the buttons, the programming state and the identifier are all candidates, and not all of them deserve the same treatment. The criterion is not what can be measured but what has to be measured to establish that the product is fit for its purpose.

The distinction to draw is between a parameter that will be verified by the design being correct and a parameter that has to be verified on every unit. A resistor value that is placed by a machine with a verified programme does not have to be measured on each board, provided the placement has been confirmed. A calibration constant or a sensor reading does, because it depends on the individual device and on the joint that connects it.

The acceptance criteria are written at the same time. A test that reports a value without a limit is a measurement rather than a decision, and it leaves the judgment to whoever reads the log. Stating the minimum, the maximum and the units turns the same measurement into a pass or a fail, and it makes the result comparable between batches and between operators.

Building the Test Fixture

The fixture is the interface between the product and the test equipment, and it is where most functional test problems actually live. It has to make reliable contact with every point it uses, hold the board in a repeatable position, support the board so that the contact pressure does not flex it, and do all of that without damaging a component or a connector that will be shipped.

The choice between a bed of nails, a connector based interface and a flying probe arrangement follows from the product. A bed of nails suits a high volume product with accessible test points and gives a short cycle time. A connector interface suits a product that already has a programming or debug port, and it has the advantage of using a connection the product was designed to provide. A flying probe suits small quantities and prototypes, where the cost of a dedicated fixture is not justified by the volume.

The fixture is designed against the released artwork and built in parallel with the production preparation, so that the first assembled batch can be tested immediately rather than waiting in a queue. A fixture designed after the boards have been built is a delay that was entirely avoidable, and it is one of the more common causes of an extended pilot run.

Programming as Part of the Test

Where the product carries firmware, programming is normally integrated into the same station rather than performed as a separate step. The board is programmed, the revision or the checksum is read back, and the functional test follows on the same fixture without the board being handled again. Combining the two removes a transfer, removes a queue and removes the possibility of a board being tested without having been programmed.

The revision check is not a formality. A board that carries the wrong firmware will often pass a basic functional test and fail in the field, and reading back the version is the only way to know which file was actually written. Where the product carries an individual identifier or a calibration value, the write and the verification of that value belong to the same station and the same record.

Handling a Failure

The value of a functional test depends on what happens when it fails. A result that identifies the failed parameter is a diagnostic; a result that only reports a failure is a puzzle. The test programme is therefore written so that the failing step is recorded together with the measured value, which allows the fault to be classified as a programming issue, a soldering issue, a material issue or a connection issue without repeating the whole sequence.

Once a board has been repaired, it repeats the corresponding test rather than being released on the basis that the fault has been addressed. The repair disturbs the board as well as the fault, and a board that has been reworked around a component is a board whose neighbours have seen a second thermal excursion.

The results also have a second use. A parameter that fails more often at a particular position, or in a particular batch of material, is telling the process something, and the test data is the evidence that makes the correction possible. Keeping the results against the batch, rather than discarding them once the boards have shipped, is what turns the test station from a gate into an instrument. Our PCBA testing service covers the fixture, the programming and the functional verification, the boards are built under SMT assembly, the prototypes start at rapid PCBA prototyping, the firmware is produced by the embedded firmware team where required, and the records are held under quality management.

Where the Test Strategy Is Decided

The test strategy is decided by the design, not by the test engineer, and this is the point most often missed when a product arrives for production. Whether a node can be probed, whether a port can be accessed, whether a board can be powered from a single supply and whether the analog channel can be measured without disturbing it all follow from choices made during the layout. A test that has to work around the design is slower, more expensive and less reliable than one the design was arranged to support.

The practical measure is to consider the test while the artwork is still open. Adding a test pad costs a few square millimetres, and adding one after the design has been released costs a new revision of the panel and the stencil. Providing a debug or programming header costs a connector and a small area, and it removes the need for the fixture to contact the board at points that were never intended for it. Locating the ground references and the supply rails where a probe can reach them costs nothing at all and saves time in every test that follows.

The second consequence is that the fixture and the test programme belong to the product rather than to the test department. The requirements, the limits and the sequence come from the specification, and the fixture implements them. Where the test is designed around the fixture’s capabilities rather than around the product’s requirements, the coverage shrinks quietly to what the equipment happens to find convenient, and the products that fail in the field are the ones whose faults fell into that gap.

Testing Across a Product Family

Where a product exists in several variants, the test station is usually arranged to serve the whole family rather than one member. The common measurements are shared, the variant specific ones are selected by the identifier that has been programmed, and the limits table is held as data rather than as code. That arrangement means a new variant can be added by extending the data rather than by building a new station, which matters when the variants are the reason the product line exists.

The identifier also solves the problem of the wrong firmware. A station that reads the variant from the board and selects both the programme and the limits cannot test a board against the wrong specification, because the board itself declares what it is. Where the identifier is written at the same station, the sequence is arranged so that the write is verified before the variant specific tests are selected, and a board whose identifier cannot be read is stopped rather than tested against a default.

FAQ

Does every parameter need to be tested? No. The test covers what has to be established on each unit; parameters guaranteed by the placement and the material are verified on the setup rather than on every board.

Why integrate programming into the test station? Because it removes a transfer, a queue and the possibility of a board being tested without the correct firmware.

What should happen after a repair? The board repeats the corresponding test, including the checks around the repaired area, before it is released.