What Is FCT and Why Your Contract Manufacturer Should Run It
You get an email from your biggest distributor. Forty-seven units from your last batch are dead on arrival. The boards look fine — every solder joint is perfect, every component placed correctly. Your CM swears they tested everything. But when your engineer powers one up on the bench, the Bluetooth radio never initializes. The firmware loads, the LED blinks, but the radio sits silent. A timing bug in the power sequencing — the kind of defect that's invisible until you actually turn the board on.
This is what hardware functional testing exists to catch. And if your contract manufacturer isn't running it, your customers are doing it for you.
The Test That Turns the Board On
Every other test method in the manufacturing line stops short of the one question that matters: does this product actually work?
Automated Optical Inspection checks that components are present and solder joints look right — it catches 99.5% of visual defects but can't tell you if the firmware is corrupted. It also can't see under BGA packages, where X-ray is required. In-Circuit Testing probes for opens, shorts, and correct component values with resistance accuracy to +/-0.1% and capacitance to +/-2%, catching 85–98% of electrical defects — but it runs mostly unpowered, so it'll never see a voltage regulator that oscillates under switching load. Flying probe testing does similar work without a custom fixture using 2–8 movable probes at 20–30 points per second, but at 5–15 minutes per board, it's too slow for production and still can't test system behavior.
Hardware functional testing (FCT) is different. It applies power, boots firmware, exercises every communication interface, reads every sensor, measures every output, and compares the results against defined pass/fail limits. A smartwatch heart-rate sensor gets fed simulated heartbeat signals; a Bluetooth radio must complete a handshake; a power supply must hold within +/-5% under load. FCT catches the 70–80% of operational defects that nothing else can reach — firmware bugs, sensor calibration drift, protocol handshake failures, and performance issues that only appear at operational speed.
| Test Method | What It Catches | What It Misses |
|---|---|---|
| AOI | Missing components, solder defects (99.5%) | Everything electrical or functional |
| ICT | Opens, shorts, wrong values (85–98%) | System behavior, firmware, timing |
| Flying Probe | Same as ICT, no fixture needed (85–90%) | Same as ICT, plus too slow for volume |
| FCT | System-level failures (70–80% operational) | Requires custom fixture and test program |
These methods aren't competing — they're layers. AOI after reflow, ICT for structural verification, FCT as the final gate. Combined, they can exceed 99% overall coverage. But drop the FCT layer and you're shipping boards that look electrically perfect but don't work as products. As one industry analysis puts it: "no one technology can come close to full test coverage".
The $5.3 Billion Lesson
In 2016, Samsung shipped the Galaxy Note 7 with compressed timelines and insufficient battery testing across two suppliers. The recall cost at least $5.3 billion. Samsung responded by implementing an 8-point battery safety check for every product going forward — the kind of testing regime they could have started with.
Philips learned a similar lesson with 5.2 million recalled CPAP devices. The write-down was €1.3 billion. The U.S. settlement was another $1.1 billion. A court ordered a complete manufacturing and quality control overhaul under independent oversight.
In another case, a capacitor failure in train braking systems passed testing by both the semiconductor manufacturer and the board manufacturer — but failed after final installation because the tests didn't replicate real operating conditions. The pattern is consistent: testing gaps that seem minor in production become existential threats at scale.
These are the extreme cases. But the economics work the same way at every scale. NXP's cost model tracks what happens as a defect escapes further down the chain:
| Where You Catch It | What It Costs |
|---|---|
| At the test station | 1× |
| At package/module test | 10× |
| At customer incoming inspection | 100× |
| At system assembly | 1,000× |
| In the field | 10,000×+ |
An electronics-specific version from Promwad maps this to hardware product development: schematic review at 1×, prototype at 10×, NPI at 100×, volume production at 1,000×, and field failure at 10,000×+. The exact multipliers are rules of thumb — nobody has ever paid exactly ten times — but the exponential shape of the cost curve is consistently supported across sources.
For consumer electronics, field failure costs land at $25–$200 per return — two-way shipping, customer support, diagnosis, repair or replacement. Industrial products run $200–$2,000 per return. Enterprise equipment hits $800–$2,400, and 25–40% of returns turn out to be "no fault found." Processing a return can consume up to 66% of the product's original price.
Now do the math on your next production run. Industry-average defect escape rates run 2–3% before advanced inspection. At 10,000 units with a 3% escape rate and $100 average return cost, you're looking at $30,000 in avoidable returns. A basic FCT station costs $5,000–$15,000 to set up and $0.50–$5.00 per unit to run. Automated test payback is estimated at 6–18 months. A European electronics manufacturer tracked this precisely: test data analytics saved EUR 4 million from reduced retesting and EUR 4.5 million from scrap reduction over seven years.
The rule of thumb: if your product sells for more than $30 and you ship more than 1,000 units per year, FCT delivers positive ROI. For most hardware startups, the question isn't whether you can afford to test — it's whether you can afford not to.
What a Real FCT Station Looks Like
Forget the image of a million-dollar cleanroom lab. A first FCT station for a hardware startup is closer to a well-organized workbench.
The fixture is a bed-of-nails jig — spring-loaded pogo pins mounted in a guide plate that press against test pads on your board, paired with a separate control board so each can change independently. Reliable center-to-center spacing is 2.54 mm (100 mil) or 1.91 mm (75 mil); tighter spacing causes missed contacts and false failures. Plates are fabricated from G10 or acrylic with precision-ground guide pins. Pogo pins last 50,000–100,000 cycles before contact resistance creeps up. Fixture fabrication takes 2–3 weeks, test development for a moderate board takes 2–4 weeks. Total fixture cost: $2,000–$10,000.
The instruments start simple: a programmable DC power supply with remote sensing, a digital multimeter, and a USB or serial connection for firmware loading. As needs grow, add oscilloscopes, electronic loads, signal generators, and sensor simulators. NI's PXI platform and Keysight's modular instruments combine multiple instruments in one chassis with software-controlled switching. Firmware is loaded via SWD for ARM Cortex-M or JTAG for complex SoCs using pogo pin contact to exposed test pads. External programmers like Segger J-Link or ST-Link cost a few hundred dollars.
The software is where your test program lives. NI TestStand is the industry workhorse — it sequences test steps written in LabVIEW, Python, or C++ with built-in reporting and database integration. But for a startup, Google's OpenHTF (Apache-2.0, open source) is compelling: Python-native, version-controlled alongside your firmware, integrable with CI/CD, and free. You write test phases that measure parameters and declare pass/fail specs. No license fees, no vendor lock-in.
The data layer is where the real value compounds over time. Every unit should generate a record keyed by serial number: every measured value, not just pass/fail, the limits applied, timestamps, operator ID, firmware version, and station ID. A bare "PASS" without the measured voltage is meaningless — it hides margin information critical for yield analysis. This per-unit record becomes the device's birth certificate — serial number, MAC address, provisioned security keys, firmware version, every test measurement — following the unit through its lifecycle.
Start manual. An operator loads the board, presses a button, reads pass/fail — 15–30 minutes per board. Iterate your test program until you trust it. Automated FCT runs in 30–120 seconds. Companies like Kitron use six-axis robots serving multiple test machines. Cobot-based platforms replace two operators per shift in dual-fixture setups. But start manual and iterate before committing to automation.
Here's what this looks like in practice: one team spent $8,000 on their first fixture and $7,000 on instruments and software. Their second product on the same architecture needed only $5,000 in interface adaptation — a 75% reduction in NPI test cost. Modular design pays for itself fast.
Why Your CM Isn't Testing (and How to Know)
Here's the uncomfortable truth: every second a unit spends on a test fixture is a second that isn't generating margin for your contract manufacturer. The CM bears the cost of testing. You bear the cost of field failures. Without explicit contractual alignment, the CM is rationally incentivized to under-test.
This doesn't make CMs bad actors. Their margins are thin and throughput pressure is real. But the misalignment is structural, and it leads to predictable shortcuts:
- Reduced coverage: They test power-on and basic communication but skip the calibration verification and parametric measurements that take longer
- Widened limits: Loosening pass/fail thresholds from +/-2% to +/-10% instantly improves first-pass yield while shipping marginal units
- Sample testing: Testing 10% instead of 100% — dangerous for functional defects that aren't randomly distributed
- Batch skipping: After several "good" batches, reducing test frequency, especially on night shifts
- Shortened burn-in: Cutting from 24 hours to 4 hours (or zero), missing infant mortality defects
How real is this? SuitePad, a German hotel tablet manufacturer, re-tests every single unit at their Berlin headquarters even though every unit already passed factory testing in Shenzhen. They built an entire second test operation because they couldn't trust the first one.
The problem is compounded by the absence of a dedicated standard. IPC-9252 covers bare (unpopulated) PCB testing only — continuity and isolation. IPC-A-610 defines visual acceptance criteria but explicitly doesn't define electrical testing. J-STD-001 covers soldering process requirements. None of them prescribe FCT procedures. The "does my product actually work?" question is entirely your responsibility to answer.
The Accountability Playbook
You don't need to distrust your CM — you need to verify. Here's how:
Write the test specification yourself. This is the single most important document in the relationship. Define every test, the sequence, pass/fail limits for each measurement, required equipment and calibration intervals, whether testing is 100% or sampled, data logging requirements, and escalation procedures. "Do not leave quality acceptance to the CM's discretion" — "testing" without specifying scope is a loophole.
Put it in the contract. Your SOW should state that the CM performs FCT on 100% of units per your specification. Warranty of conformity: typically 12–24 months. Liability caps should be at least 2× annual purchase value with carve-outs for gross negligence. And the critical clause: no changes to the test program, limits, or sequence without your written approval.
Run First Article Inspection. FAI validates the production line, not your design. Build 3–5 first articles and run the full test program on each. Trigger FAI on every component change, supplier change, or factory move.
Audit remotely with data. Test data platforms let you see what's happening in real time. Maintain a "golden unit" and periodically send it through the CM's test line. Use Cp and Cpk metrics to evaluate whether measurements are safely within limits. Watch for red flags:
- All units passing with identical measurements (test isn't actually running)
- Yield jumping from 95% to 99.5% overnight (limits were loosened)
- Test cycle time decreasing (tests were removed)
- Gaps in serial number sequences (units were skipped)
- Timestamps showing impossibly short intervals between units (data was fabricated)
Own the data and the fixtures. You own the test specification, pass/fail criteria, and every byte of test data. Fixtures should be your property with the CM acting as custodian. Even if the CM develops the test program, you must understand what it covers — "the CM doesn't have a full grasp on the tests when the OEM does not supply enough information".
Start Here
The gap between structural testing and functional testing isn't a matter of degree — it's a difference in kind. One verifies the assembly process worked. The other verifies the product works.
For a hardware startup moving from prototype to production, here's your starting point: a manual pogo-pin fixture, a programmable power supply, a DMM, and a Python-based test sequencer like OpenHTF. Under $15,000. Running in weeks. The test data from day one becomes the foundation for yield improvement, design iteration, and the proof you need to hold your CM accountable.
Every unit you ship without functional testing is a bet — a bet that the firmware loaded correctly, that the sensor calibrated within spec, that the radio initialized, that the power supply doesn't oscillate under load. Some of those bets will lose. The question is whether you find out at the test station or from a customer's one-star review.
The companies that treat FCT as optional are the ones whose customers become their test department.
Sources
- Promwad — The Hidden ROI of Test Engineering in Hardware
- FixturFab — Functional Testing Methods
- RayPCB — PCB Testing Coverage Analysis
- NXP — The Economics of Test, Yield, and Late Detection
- ANSI — IPC-9252A Standard
- TST Ronic — Understanding IPC-A-610
- Electronic Design — Test Coverage Feasibility
- PCBOnline — Functional Testing of PCB Assembly
- Promise Legal — Hardware Startup Manufacturing Agreements
- iConnect007 — PCBA Test Management Practice
- WATS — OEM Responsibility and Test Data Management
- Kitron — Automated FCT Platform
- SuitePad — Building Hardware and Ensuring Quality
Have thoughts on this? Join the discussion on our forum.