Write the fixture brief as a map from product behavior to a repeatable test setup. Name the DUT revision, connector pinout, safe power sequence, loads, firmware, communication settings, stimuli, measurements and pass/fail limits. Give fixture hardware, cable assemblies and test software separate version IDs. A pilot unit is useful only when its result can be traced to the exact board, program, fixture and limits that produced it.

What inputs are required before functional-test fixture development?

Provide the current product definition plus an executable test list. The minimum package includes schematic, BOM, assembly and mechanical data, connector pinouts, power-tree information, firmware/programming files, interface protocols, required loads or simulated peripherals, safety constraints and a step-by-step list of observable behaviors. For every measurement, state the condition, point, unit, lower and upper limit and what happens after a failure.

Functional-test fixture brief inputs
Input groupWhat to provideQuestion it closes
DUT identityPCBA number/revision, variant, assembly drawing, BOM and mechanical envelope.Which physical and electrical product is being tested?
InterfacesConnector, pinout, mating part, communication mode and signal direction.How does the fixture contact and communicate with the DUT?
Power and loadsSupply rails, current limit, sequence, discharge, loads and isolation.How can the DUT be energized without masking a fault or causing damage?
SoftwareFirmware image, configuration, programmer, test sequence and dependencies.Which code and state make the expected behavior valid?
AcceptanceStimulus, measurement point, unit, limits, timing and failure action.What exactly produces PASS or FAIL?
RecordsUnit ID, timestamp, versions, measured values, failure code and retest history.Can the pilot result be repeated and compared later?
AI-generated illustration: generic PCBA fixture with product connectors, power cables, grounding and strain relief
AI-generated illustration — connector and cable details are conceptual and do not represent a PCBArise fixture, customer product or approved wiring design.

How should DUT interfaces, power, loads and communications be defined?

Define every interface by pin, direction, electrical state and test purpose. For a connector, name the mating part or controlled adapter, pin map, keying, insertion method and cycle-life concern. For power, state nominal input, current limit, polarity protection, sequencing, settling time and a safe way to remove stored energy. For a load or simulated peripheral, identify operating modes and tolerances rather than writing “connect normal load.”

Communication tests need protocol, physical layer, address, bitrate, termination, command, expected response and timeout. Analog measurements need point, reference, bandwidth or settling condition, unit and limits. Digital I/O needs pull state, drive level and whether the fixture stimulates, observes or both. These details turn a functional claim such as “USB works” into a repeatable operation.

How do fixture, test program, cables and product versions stay matched?

Give each item its own revision and store their approved combination in a compatibility table. The fixture mechanical assembly can change without a software change; a cable pinout can change without moving the DUT; firmware can change expected messages or timing without altering the board. One shared label such as “FCT v2” hides those differences.

Version map for a pilot functional test
ItemVersion identityCompatibility fieldChange that requires review
DUTPCB/PCBA part, revision and variantSupported fixture/cable/program setConnector, rail, I/O, component or mechanical change
Fixture hardwareFixture assembly and wiring revisionDUT envelope and access mapLocator, support, probe, interlock or wiring change
Cable/interface setCable part and pinout revisionConnector and signal assignmentMating part, wiring, shielding or load change
Test softwareApplication and sequence revisionLimits file, instrument setup and DUT firmwareStep, command, timing, calculation or limit change
DUT firmwareImage/configuration ID and checksumExpected protocol and behaviorBoot, interface, calibration or output change
AI-generated illustration: engineer reviewing a generic test sequence and firmware setup beside a PCBA fixture
AI-generated illustration — screen blocks are intentionally generic; this is not PCBArise software, customer firmware or a real test result.

How is functional test different from ICT, flying probe and programming?

Functional test demonstrates only the powered behaviors the sequence exercises. ICT and flying probe focus on accessible structural or component-level electrical checks and can help localize assembly faults. Programming writes or verifies device code or data. A fixture may combine operations, but combining hardware does not make their evidence interchangeable.

What each operation establishes
OperationPrimary questionTypical inputWhat it does not prove alone
ICTAre selected accessible nets/components structurally correct?Fixture, netlist, targets, program and limits.Complete end-use behavior.
Flying probeDo selected reachable nets/components meet programmed checks?CAD/netlist, coordinates, access and program.Inaccessible features or all product functions.
ProgrammingWas the intended image/data written and verified?Device, interface, image, configuration and verify method.That every hardware function operates.
Functional testDoes the DUT perform the specified behavior under stated conditions?Power, interfaces, firmware, stimuli, loads and limits.Untested behavior or every possible assembly defect.

What results should a PCBA pilot build record?

Record enough context to reproduce a result, not only PASS or FAIL. Capture the unit serial or pilot ID, PCB/assembly revision and variant, BOM deviation status, DUT firmware/configuration, fixture and cable revisions, test-software/sequence and limits versions, instrument identity when measurement traceability matters, timestamp, operator or station, measured values, failure code, retest history and final disposition.

Keep the first failures. A pilot is where connector seating, fixture alignment, power sequencing, limit selection and software timing are most likely to change. Deleting early runs erases the information needed to separate a fixture problem from a product problem. Mark invalid setup runs explicitly instead of rewriting them as product passes.

1. Define behaviorWrite stimulus, condition, measurement, unit, limits and failure action.
2. Design the interfaceMap connectors, power, loads, safety, support and service access.
3. Build the baselineVersion fixture, cables, firmware, software and limits separately.
4. Validate the pilotRun known conditions, keep failures and publish the compatible version set.
AI-generated illustration: engineer comparing a generic reference board and pilot PCBA at a functional-test fixture
AI-generated illustration — the boards and fixture are generic and do not claim a PCBArise pilot build, known-good unit or validation record.

What should the copyable fixture brief say?

Use one line per test behavior and one version table for the complete setup. Avoid phrases such as “test all functions” or “normal limits.” They do not define an instrument action or an acceptance decision.

Fixture brief example: “DUT: [part/revision/variant]. Interface: [connector/pin map/cable rev]. Apply [input] with current limit [value] and sequence [steps]. Load [output] with [load/mode]. Install firmware/configuration [ID/checksum]. Stimulate [condition]. Measure [point/parameter] after [settling/time window]. PASS when [lower limit] ≤ [value and unit] ≤ [upper limit]. On FAIL: remove power safely, record [code/value], and route to [diagnostic action]. Record fixture, cable, software, limits and firmware revisions with the unit result.”

How should the pilot fixture be validated before repeat production?

Challenge the setup with known conditions and repeat the mechanical and electrical sequence. Verify connector keying, board seating, support, interlocks, current limiting, discharge and operator access. Run a known reference state plus deliberate open, wrong-connection or limit-boundary conditions that the fixture can safely simulate. Confirm that a repeated good unit produces stable measured values and that a known failure is reported by the intended step.

The outcome is a compatible set of fixture, cables, test software, firmware and limits, plus an unresolved-issue list. It is not a universal coverage percentage. Use the test-point design guide for internal access and the method comparison when a structural test should complement FCT. For a project-specific route, connect the finished brief to PCB assembly testing.