Functional test (FCT) is the pass/fail gate at the end of a PCBA manufacturing line. After the board has been assembled, soldered, inspected, and—where applicable—in-circuit tested, FCT is the step that answers the only question that actually matters to the end customer: does this board do what it is supposed to do when it is powered up and exercised like it will be in the field?
For general commercial electronics, that question can often be answered with a relatively simple go/no-go test. For aerospace and defense PCBAs—training boards used in fighter jet simulators, interface cards in avionics test stacks, control boards in ground support equipment—the answer has to be documented, traceable, and defensible to an auditor. The functional test strategy drives a lot of that.
This post walks through what functional test does, where it fits relative to the other PCBA test methods, and what changes when FCT is applied to a build-to-print program for a regulated industry.
A complete PCBA test strategy usually involves multiple, complementary test methods. Each one catches a different class of defect:
FCT is the last of these in the sequence, and it is the one that most closely approximates what the board will experience in its end application. Unlike ICT, which accesses the board at the node level through a bed-of-nails, FCT typically interfaces at the connector level—the same way the board will be connected in the field. That makes FCT fundamentally about behavior rather than structure.
A well-designed functional test exercises the board the way its end application will. For most PCBA programs, that includes some combination of:
A functional test that is doing its job catches parametric failures (a component that is in range at ICT but drifts under load), interaction failures (two subsystems that pass individually but fail when the board is fully powered), firmware anomalies, and assembly defects that made it past AOI and ICT. It will also, for most programs, log the measured values—not just pass/fail—so that marginal units and trend drift can be caught before they become field failures.
Aerospace and defense PCBA programs carry test strategy requirements that go beyond what commercial boards typically need. A few differences worth naming:
Documentation and traceability
For programs operating under ITAR, AS9100 flow-downs, or DoD quality requirements, FCT data isn't just internal process information. Measured values, serial-number-level test records, operator IDs, calibration status of the test equipment itself, and deviation documentation all become part of the board's as-built record. First Article Inspection (FAI) reports and Certificates of Conformance depend on the FCT data package being complete and auditable.
Test equipment configuration control
The test system used to qualify an aerospace PCBA is itself part of the controlled process. Changes to the test sequence, instrument firmware, or fixture—even seemingly minor ones—can trigger a requalification. FCT platforms for A&D work are built with configuration control in mind: versioned test sequences, logged instrument firmware, calibrated and traceable measurement chains.
Obsolescence and legacy boards
A substantial portion of aerospace FCT work involves boards whose original test fixtures and test software are no longer supported by the original equipment manufacturer. Building a functional tester for a legacy PCBA often means reverse-engineering the original test intent from incomplete documentation, sourcing replacement instruments where the originals are obsolete, and validating that the new test produces results consistent with the historical acceptance criteria. This is common on legacy flight recorder test programs, fighter aircraft support equipment, and depot-level test stands.
Higher cost of field failure
A commercial PCBA that fails in the field causes an RMA. An avionics PCBA that fails in the field can ground an aircraft. The test plan is scoped accordingly—more thorough fault coverage, more margin testing, and more emphasis on catching parametric drift at FCT rather than letting it propagate.
When Ball Systems manufactures a PCBA build-to-print, the customer owns the design and the test definition. Our job is to execute the assembly and the test the customer specified, not to redesign the board or reinterpret the test strategy.
In practice, "execute the test" can mean several things depending on what the drawing package includes:
All three paths are normal. The choice is driven by what the customer is trying to accomplish—pure contract manufacturing, delivery of both boards and test capability, or development of test infrastructure around an existing design.
A recurring pattern on PCBA programs with multiple variants is that each variant gets its own dedicated functional tester. Over time, that produces a line with six, eight, or a dozen similar-but-not-identical test stations—each one occupying floor space, each one requiring its own calibration schedule, each one requiring its own operator training.
A universal test platform consolidates that. One hardware platform, configurable through software and interchangeable fixtures, tests the full family of DUTs. Done correctly, the consolidation reduces floor space, reduces operator count, reduces calibration overhead, and produces a test record format that is consistent across the product line.
Done poorly, it produces a platform that technically supports every variant but does none of them well. The difference is whether the test requirements for every DUT in the family were available and analyzed before the platform architecture was frozen. If a customer is considering a universal approach, the preparatory work is providing the complete function list, test parameters, and acceptance criteria for every variant up front—not after the first variant is in production.
Ball Systems has built universal test platforms for both commercial and aerospace applications. The white paper linked below walks through the architecture and trade-offs in more detail.
If you’d like to read more about how we work with our customers to design and build universal test systems, check out the following white paper.