An ICT and FCT test strategy defines which manufacturing faults and product behaviors must be proven, where each check occurs, what design access and equipment it needs, how the result is accepted, and how the evidence remains valid after change. It is not a simple choice between two machines.
In-circuit test is valuable for controlled access to nodes and components, structural diagnostics, measurements, and programming tasks supported by the fixture and program. Functional circuit test powers the assembly in a defined environment and evaluates selected behavior at interfaces and outputs. Neither method proves everything, and a passing result is meaningful only within its released fault list, setup, limits, and traceability.
This guide addresses the release decision before NPI and repeat production. The GNS comparison of ATE and flying probe testing provides adjacent method context. Here the OEM task is to decide whether ICT, FCT, both, or a justified alternative sequence produces the evidence needed for the actual PCBA and business case.
Decide the fault and behavior targets first
Test planning begins by mapping manufacturing faults and required behaviors to the released assembly. The correct method follows the decision that the data must support. Start with faults, risks, product behavior, and production economics before requesting a fixture quote.
Build a product risk and fault list
List credible assembly faults by feature and process: open and short circuits, wrong or missing values, reversed or misoriented parts, solder defects, damaged devices, connector or switch problems, programming failure, power-rail faults, calibration error, interface failure, and behavior that only appears under a defined load or sequence.
For each item, record severity, occurrence concern, detectability by available methods, diagnostic value, affected product stage, and release consequence. Link it to the schematic, net, component, reference designator, interface, requirement, or function. “Test the board” is not a test objective.
The GNS guide to AOI, X-ray, ICT, and FCT for OEM buyers explains why inspection and test methods observe different evidence. Use that division to avoid assigning a hidden-joint structure, component value, powered behavior, and final system function to one undefined “100% test.”
Separate structural evidence from behavior
Structural evidence asks whether the assembly was built correctly within accessible and modeled conditions. ICT can target shorts, opens, analog values, device presence or orientation, powered or unpowered measurements, boundary scan, vectorless checks, and programming when the system and fixture support them.
Keysight describes in-circuit test systems as board-level diagnostic tools that use test-point access and can address structural defects, component measurements, boundary scan, vectorless techniques, and program development. Treat the page as vendor method information, not a claim that every ICT system or board has the same coverage.
Behavioral evidence asks whether the powered PCBA performs selected functions under controlled stimulus, load, communication, timing, calibration, and environmental conditions. FCT can exercise interfaces and operating sequences, but its diagnostic resolution depends on the fixture, software, measurements, and test design.
Model volume cost and diagnostic value
Separate nonrecurring engineering from recurring test cost. ICT may require DFT work, a bed-of-nails fixture, program generation, models, debug, maintenance, probe replacement, and revision rework. It can provide fast, localized diagnosis at production volume. FCT may require custom mechanical interfaces, instruments, loads, simulators, cables, safety controls, software, calibration, golden references, and longer sequences.
The decision should compare forecast volume and product life, mix and variants, cycle time, parallelization, fixture life, maintenance, false failures, debug time, repair savings, escape risk, and cost of a missed defect. NI’s manufacturing-test paper on lowering the cost of test describes process tests such as ICT earlier in the line and functional test at one or more points, with access, throughput, development, and support tradeoffs.
Do not select ICT because volume is “high” or FCT because a product is “complex” without quantifying the decision. A diagnostic result that reduces hours of debug may justify cost even at modest volume; a fragile fixture or long test may destroy the assumed saving.
Release the ICT access fixture and program
Electrical coverage depends on released nodes, accessible contact points, product mechanics and the selected test method. ICT performance is designed into the product and release package. Test access, fixture mechanics, models, limits, and program configuration must agree before production evidence is accepted.
Freeze design and DFT inputs
Provide the released PCB and panel data, netlist, BOM and approved sources, placement and assembly data, schematics, test-point list with coordinates and side, component models, variant rules, keep-outs, board outline, tooling holes, support needs, panel breakaways, connector access, programming requirements, target faults, acceptance rules, and expected volume.
Resolve whether pads are probeable after soldering, coating, shielding, press-fit, mechanical assembly, or depaneling. Check probe diameter, spacing, surface finish, side access, board flex, component height, bottom-side interference, connector clearance, high-current paths, sensitive analog nodes, RF structures, differential pairs, isolation boundaries, and power sequencing.
The GNS BOM and Gerber checklist provides the wider data reconciliation. The test package must additionally identify the electrical objects, probe access, mechanical reference, and safe test state.
Design the fixture around the released assembly
Define fixture type, actuation, probe field, board support, top and bottom access, connectors, clamps, guarding, interlocks, ESD controls, cable routing, service loops, changeable plates, wear parts, serial or barcode reading, and operator loading. Specify the mechanical stack and tolerances that determine repeatable contact.
Do not let probe force bow the PCBA or load fragile components. Protect high-voltage, high-current, battery, motor, relay, RF, and safety-critical circuits with the required isolation, current limits, discharge, interlocks, shielding, and safe failure state.
Teradyne’s in-circuit testing overview shows that ICT platforms can combine structural methods, boundary scan, programming, automation, and focused functional operations. That flexibility does not remove the need to declare the actual fixture, modules, access, and sequence used for the product.
Validate models programs and limits
Generate the test program from the released netlist, BOM, layout, component models, and target fault list. Review tests that were disabled, guarded, merged, learned, relaxed, or made inaccessible. Record why a modeled component cannot be measured and what other evidence addresses the risk.
Validate the program with known conditions, instead of relying on one golden board” Confirm contact checks, shorts and opens, component measurements, polarity or vectorless checks, boundary scan where used, power-up order, programming, discharge, retest, and data output. Challenge known or seeded faults where practical and safe.
Keysight’s technical overview of component tolerance and ICT test limits is relevant because tolerances from components, measurement uncertainty, guarding, circuit interaction, temperature, and fixtures affect limits. Record the engineering rationale rather than widening limits until a board passes.
ICT release gate
Evidence required before production use
Data
Released PCB, panel, netlist, BOM, placement, schematics, variants and target fault list
Access
Probe coordinates, sides, sizes, spacing, keep-outs, electrical risk and uncovered nodes
Fixture
Mechanical stack, support, actuation, probes, connectors, interlocks, ESD and wear plan
Program
Test types, models, disabled tests, sequence, power, programming, limits and revision
Validation
Contact challenge, known conditions, fault checks, repeatability, false calls and safe failure
Output
Unit identity, result, measurements, failure code, fixture and program revision, disposition
Release FCT behavior fixtures and limits
FCT release controls stimuli, loads, instruments, fixture interfaces, software, limits and safe states. FCT must translate product requirements into a reproducible production sequence. “Power on and check function” is not a controlled test specification.
Define states stimuli loads and measurements
List each function and operating state to be tested. Define input power, current limit, startup and shutdown order, firmware or bootloader, communication commands, simulated sensors, loads, switches, relays, motors, displays, audio, RF, network, analog and digital I/O, timing, calibration, and expected outputs.
Specify exact measurement points, units, bandwidth, sample rate, dwell, stabilization, triggering, averaging, tolerance, guard band, and decision logic where relevant. Separate requirements verified at PCBA level from those that require an enclosure, antenna, thermal path, harness, sensor, actuator, battery, calibration environment, or complete system.
NI’s electronics functional test overview emphasizes modular instruments, software, standardized architectures, data, parallelization, and sustaining the station across NPI and production. Use the product specification and validated station as the governing release.
Control fixture instruments and software
Identify the FCT fixture, nest, connectors, pogo interfaces, cables, adapters, loads, simulators, power supplies, instruments, communication devices, reference standards, safety hardware, and calibration status. Record hardware serials or controlled configuration where required.
Protect the unit and operator against reversed insertion, incorrect power, short circuits, stored energy, hot surfaces, moving parts, RF exposure, and unsafe output. Define interlocks, current and voltage limits, emergency stop, discharge, and the response to communication loss or software crash.
Control operating system, drivers, firmware loader, test executive, sequence, libraries, instrument configuration, limit file, variant selection, database schema, and report template. A fixture that appears unchanged can produce different results after a driver, library, limit, or firmware update.
Validate behavior and diagnostic boundaries
Test known-good and known-fault conditions across expected product and station variation. Confirm connector mating, fixture repeatability, instrument uncertainty, warm-up, stabilization, noise, communication timing, operator handling, and result storage. Challenge every critical failure path and safe-state response.
FCT should show which requirement or behavior each step addresses and which faults remain ambiguous. A failed power rail may be reported by many later steps; sequence design should stop safely, preserve the primary observation, and avoid misleading cascades.
NI’s production and manufacturing test material describes functional test stations as systems that must balance coverage, performance, cost, deployment, and maintenance. The PCBA release still requires product-specific stimuli, loads, instruments, limits, expected responses, and traceability.
Do not use a golden unit as the only acceptance authority. It can support correlation and station checks, but released numerical or logical requirements must control production decisions.
Connect sequence failures and retest decisions
The first failure, diagnosis, repair and impacted retest must remain connected to the unit record. ICT and FCT create value when their sequence, failure codes, diagnosis, containment, and retest rules are connected. Otherwise the same defect may consume two stations without producing a clear decision.
Place each test where it changes the decision
Use earlier structural checks when they prevent a faulty board from consuming expensive programming, calibration, burn-in, or long functional sequences. Use FCT after the assembly state includes the interfaces and firmware needed for meaningful behavior. Some products benefit from focused functional checks at ICT and a separate end-of-line sequence; others require a different order.
Record prerequisites for each stage: inspection complete, rails safe, programming state, serial assigned, calibration status, connectors installed, coatings cured, mechanical parts present, and prior result accepted. Do not let an operator bypass a failed prerequisite by restarting a later station.
Keep the sequence aligned with repair economics. If a fault can no longer be diagnosed or repaired after coating or enclosure assembly, detect it before that operation when technically feasible.
Map coverage gaps without double counting
Create one matrix across AOI, X-ray, flying probe or ICT, boundary scan, programming, FCT, calibration, burn-in, final inspection, and product validation. For each fault or requirement, distinguish direct detection, indirect indication, diagnostic isolation, and no coverage.
Do not add coverage percentages from different methods. Methods overlap and their denominators differ. A FCT step that fails when an input channel is inactive may indicate many structural causes; it is not equivalent to direct coverage of every component and joint on that path.
When ICT access is removed by density or mechanics, document the lost nodes and decide whether design change, boundary scan, vectorless test, flying probe, targeted measurement, improved functional diagnostics, AOI, X-ray, process control, sample inspection, or accepted residual risk addresses the gap.
Control failures repair and retest
Define failure codes with sufficient detail for containment and trend analysis. Preserve raw measurements, step, limit, sequence, program, fixture, station, unit, time, and operator or automated context. Retain the first failure; do not overwrite it with a later pass.
Failure decision
Required action and evidence
Contact or fixture fault
Contain result; verify fixture channel, probe, connector or cable; repeat only after documented station recovery
Unit manufacturing fault
Identify affected unit and lot; diagnose; approve repair or reject; repeat impacted inspection and test
Program or limit defect
Stop affected production; bound prior results; correct and validate revision; define regression and reprocessing scope
Intermittent result
Preserve sequence and measurements; control repeated cycling; investigate unit, fixture, timing, software and environment
No-fault-found
Do not auto-pass; record attempts and state; escalate diagnostic gap and disposition authority
Pass after repair
Link original failure, repair instruction, replaced item, reinspection, retest scope, final result and approver
Set retest limits and escalation rules. Endless retest can turn intermittent faults, weak contacts, marginal limits, or unstable software into false passes. The decision should state whether the unit is accepted, repaired, reworked, quarantined, submitted for engineering review, or rejected.
Maintain traceability change and commercial control
Test strategy is an asset with a lifecycle. The OEM and EMS provider must agree who owns it, what is delivered, and how changes are released.
Link results to the delivered unit
Record unit or panel serial, lot, product and variant, PCB and BOM revision, firmware, station, fixture, instrument or controlled station configuration, program and limit revision, start and end time, result, measurements or required summary, failure and retest history, repair, deviation, and approval.
Use stable identifiers and time synchronization. A CSV named with the customer part number is not sufficient if it cannot be tied to the delivered serial or if later edits cannot be detected. Define retention, export, backup, access, and customer review requirements.
IPC-1782B establishes risk-based manufacturing and supply-chain traceability covering products, processes, assemblies, parts, components, and equipment. Select the applicable level and fields contractually; do not claim that one test log satisfies all requirements.
The GNS guide to PCBA traceability before placing a PO gives the procurement questions. Add test-program, fixture, limit, firmware, failure, repair, and retest links to that chain.
Define ownership deliverables and access
State who owns the fixture design, mechanical files, probe list, wiring, models, test source code, binaries, libraries, instrument configurations, passwords, licenses, golden references, validation data, reports, and maintenance records. Define what the OEM receives and what remains supplier intellectual property.
Agree storage, transport, insurance, preventive maintenance, probe and cable replacement, calibration, spare parts, fixture duplication, site transfer, obsolescence, and end-of-life disposition. Identify recurring charges for setup, maintenance, debug, revision, and data retention.
Protect continuity. If the supplier, station, instrument, software license, operating system, or fixture vendor changes, determine what source files, adapters, reference units, models, and validation evidence are needed to reproduce the released result.
Build the revalidation trigger matrix
Review changes to PCB connectivity, layout, panel, test points, component value or source, package, firmware, bootloader, calibration data, connector, harness, mechanical assembly, fixture, probes, cables, loads, instruments, calibration, operating system, driver, library, test sequence, limits, data interface, line, site, repair method, and customer requirement.
For each trigger, define the owner and evidence: document comparison, access analysis, fixture modification, contact study, program regression, correlation unit, seeded fault, targeted ICT, targeted FCT, full first article, product validation, customer approval, or no action with documented rationale.
Release the changed configuration before use. Identify the serial or lot boundary and assess prior inventory or results when a program or limit defect is discovered. A renamed program with the same file version is not objective evidence of equivalence.
Conclusion
An ICT and FCT test strategy is ready for PCBA release when every required manufacturing fault and product behavior has an assigned, bounded source of evidence. Start with the product risk and fault list, then decide what ICT can directly diagnose through controlled access and what FCT must prove through powered stimuli, loads, interfaces, measurements, software, and limits.
Release the fixtures, programs, models, instruments, safety controls, failure codes, and retest logic as one configuration. Preserve the first failure and connect every result to the actual unit, firmware, station, program, limit, repair, and approval. Finally, define ownership, lifecycle cost, data delivery, and the design or test changes that reopen validation. The goal is not to claim complete coverage; it is to make the uncovered risk, evidence boundary, and production decision explicit.
Send the released PCB data, BOM, netlist and schematics, test-point and connector definition, firmware and functional requirements, volume forecast, acceptance limits, and change rules for an ICT/FCT strategy review.
Request an ICT/FCT Strategy Review
FAQ
Does a PCBA need both ICT and FCT?
Not automatically. The decision depends on manufacturing fault risk, electrical access, product behavior, diagnostic needs, volume, fixture and program cost, throughput, and customer requirements. Some products justify both methods, others use targeted ICT or flying probe plus FCT, and some require different structural or functional evidence.
Can FCT replace ICT on a dense PCBA?
FCT can prove selected powered behaviors but may not isolate or detect every manufacturing fault. If dense layout limits physical access, the team should document the uncovered structural risks and consider boundary scan, vectorless methods, flying probe, AOI or X-ray, design changes, functional diagnostics, or other evidence rather than assume FCT is equivalent to ICT.
What data is needed to quote an ICT fixture?
Provide the released PCB and panel data, netlist, BOM, placement and assembly data, schematics, test-point coordinates and side, keep-outs, board support and mechanical constraints, component models where required, programming needs, target fault list, product variants, expected volume, cycle-time objective, result format, and revision-change rules.
Which changes require ICT or FCT revalidation?
Review changes to PCB connectivity or mechanics, component source or value, test access, fixture, probes or cables, instruments, calibration, program, limits, firmware, bootloader, functional sequence, external loads, safety controls, product variant, data interface, repair route, line or site, and customer requirements. Repeat only the evidence affected by a documented risk assessment.
