PCB functional testing versus PCBA functional test

What should “functional test passed” tell the buyer?

It should identify the product configuration and the functions exercised under defined conditions. A test at one supply voltage or load does not establish operation across all conditions, nor does it replace a separate reliability qualification.

Review the evidence fields and engineering example

What is the difference between PCB and PCBA testing?

People often say “PCB functional testing” when they mean testing a populated circuit-board assembly. Strictly, a bare PCB is an interconnect structure without the full population needed to perform the product’s electronic functions. Its electrical test checks the specified conductive networks. A PCBA functional test applies defined stimuli to an assembled circuit and observes the required behavior.

The distinction matters when requesting a quotation. “Test every PCB” can mean continuity and isolation of bare boards, structural checks after assembly, or a complete powered product sequence. The supplier needs to know which result you actually require. State the board condition and the measurable functions rather than relying on the acronym FCT alone.

This page owns that terminology and the preparation of a functional-test requirement matrix. The existing FCT test guide remains a deeper related resource; the URLs are preserved rather than redirected or duplicated into two identical articles. For bare fabrication requirements, use PCB electrical testing.

Start with a requirement that can be observed

A useful functional requirement has an identifier, a defined stimulus, a controlled product state and an observable result. “Board works” is not a test specification. “Output voltage remains within the approved limits at the specified input and load after stabilization” is closer, provided the actual values, timing and method are documented.

Identify the firmware version, configuration and calibration state that the test expects. A board can respond differently with another image or setting even when its hardware is unchanged. If programming is part of production, define how the intended image and identity are verified and how protected or customer-owned files are handled.

For communication functions, define the interface, messages, timing and expected response. For analog functions, define stimuli, units, ranges, settling conditions and the measurement method. For power functions, agree the load and the permitted operating conditions. Specialist equipment and appropriate procedures may be required; an enquiry form should not invent operating settings.

Build a requirement-to-test matrix

The tool below creates a small, readable test matrix. Add up to eight numeric requirement rows with an ID, stimulus or condition, observation, unit and lower/upper limits. You may enter a measured result for a planning example or a supplied record. At least one bound is required for a bounded numeric check; a missing measured result remains “not executed.”

The tool validates the entered matrix structure and compares a supplied numeric result with inclusive limits. It does not connect to the board or measurement equipment, execute firmware, assess instrument uncertainty or prove that the stimulus was applied. A row described as within entered limits is a comparison of user-supplied numbers, not an independent production pass.

Not every function is a bounded numeric value. Protocol sequences, waveform shapes, safety behavior and state-machine transitions can require richer procedures. Record those in the approved test specification and link the requirement IDs to the relevant evidence. Do not force a complicated functional behavior into an arbitrary single-number score.

Fixtures, loads and instruments are part of the test

The fixture presents the correct interfaces and supports repeatable connections. Its wiring, pin map, interlocks, contact condition and mechanical support can influence the result. A mismatch between the fixture revision and the product revision can create misleading failures or leave a function untested.

Define the instrumentation by measurement need: range, resolution, uncertainty, timing and interface capability. Include cable and fixture effects where they are significant. Calibration status alone is not a complete measurement method; the procedure must explain how the relevant quantity is obtained.

NI’s electronics test overview provides an equipment-provider view of automated functional-test systems. It helps frame the architecture, but a product-specific requirement set still determines the instruments, fixtures and sequence. No particular equipment option is promised by this page.

For circuits requiring hazardous energy or special handling, the responsible test team must establish the appropriate setup and procedure. The public planning tool intentionally does not provide wiring instructions or automatically select supply and load settings.

An effective production sequence

1. Identify the unit. Match product, revision, serial or lot and intended variant.
2. Confirm prerequisites. Complete the required inspection, structural tests and fixture checks before the relevant powered steps.
3. Set the state. Apply the approved firmware, configuration, stimulus and load conditions.
4. Measure and compare. Execute the defined cases with controlled timing and limits.
5. Record and dispose. Preserve results and route failures, retests and reworked units under the agreed procedure.

Keep aborted, not-executed and failed tests separate. If a prerequisite stops the sequence, later cases have not passed merely because no failure value was generated. A report should expose those states and preserve the reason for termination.

Retries need a defined purpose. Reconnecting a fixture can diagnose a contact issue, but repeatedly running until a pass appears can conceal intermittent behavior. Retain the initial result and the disposition where required. A corrected firmware or fixture version should be traceable to the affected retest.

Functional coverage is not structural coverage

A functional sequence exercises the states and measurements included in its specification. It may not activate every circuit path, reveal every marginal joint or expose behavior at conditions outside the test. Passing a room-temperature sequence does not automatically establish environmental reliability or lifetime.

Keep production screening separate from design qualification. Production tests should detect the defined manufacturing or configuration problems efficiently. Qualification can require wider operating conditions, stress sequences and sample plans. A short FCT program does not replace the product’s entire verification and validation plan.

ICT can find selected electrical structural problems before or alongside FCT. AOI and X-ray inspection answer different geometry questions. Select the combination from product risks and access; adding the names of all methods to a page does not define an effective test plan.

When reporting coverage, identify whether you mean executed requirements, operating states, nodes or modeled defects. For the matrix on this page, completeness refers only to the entered requirement rows and their supplied observations. It is not a percentage of all possible product failures.

IPC workmanship and product function use different criteria

IPC-A-610 and J-STD-001 support the applicable assembly acceptance and process requirements. Functional limits usually come from the product specification, approved test procedure and customer requirements. Confirm the relevant document editions and class through the contract; use the IPC directory for revision status rather than treating an online worksheet as an acceptance standard.

A functional result cannot excuse an assembly defect that violates the agreed workmanship criteria. Conversely, acceptable workmanship does not demonstrate that firmware, analog performance or communications satisfy the product requirements. The release decision combines the required evidence instead of substituting one type for another.

Specify the report fields before production: unit identity, firmware/configuration, test and fixture revisions, equipment identification where required, measured values, limits, result state and disposition. Agree data retention and delivery expectations, including whether a concise certificate or detailed test log is needed.

How to request an actionable PCBA functional-test quote

Send the assembly files, schematic, BOM, expected quantities, functional requirements and any existing fixture or program information. Identify who supplies firmware, loads, cables, reference units and approved expected results. Mark unfinished requirements so the engineering estimate can include the work needed to resolve them.

Separate test engineering and fixture development from recurring test time and reporting. A new program can require significant preparation even for a small build. Repeat costs depend on sequence length, handling, equipment use and the agreed failure process; this page does not present an invented universal FCT price.

Use first-piece inspection and release to confirm the initial build and test readiness. Return to PCB Assembly for the manufacturing enquiry or quality assurance for supplier and record requirements. You can contact the team directly without completing the tool.

Functional test evidence at requirement level

Use these fields to scope the report with your quotation. The table is a planning example, not a RAYPCB test result or a promise that every record is included by default.

Continue to plan the dedicated production FCT sequence and cycle.

The email link opens a draft for you to complete. Contact is a separate form; these pages do not send messages automatically.

Questions engineers and buyers ask