PCBA test requirements in an RFQ should let two qualified EMS providers quote the same technical obligation. A phrase such as “100% tested,” “full functional test,” or “ICT required” does not do that. It names a method or frequency without defining the product risks, test conditions, limits, fixture, software, evidence, failure handling, ownership, or release decision.
The RFQ should convert the OEM’s design intent into a manufacturing-test contract. It should tell the supplier which faults and behaviors matter, what product configuration is being tested, which methods are required or open for proposal, what each method must prove, and what record closes the gate. It should also expose cost drivers before quotation: test access, fixture complexity, instruments, programming, safety controls, cycle time, diagnostics, maintenance, data retention, and customer approval.
This guide is for test, quality, NPI, hardware engineering and technical procurement teams. It focuses on the information needed to obtain a comparable proposal and a controlled production release. It does not prescribe one universal AOI, X-Ray, flying-probe, ICT or FCT route. The right route depends on product risk, design access, volume, required evidence and the faults that downstream tests can actually observe.
Define PCBA test requirements from the RFQ baseline
A test supplier cannot estimate coverage, fixture effort or cycle time against an unstable product baseline. Identify the PCB, BOM, assembly drawing, firmware and mechanical revisions included in the quotation. State whether the request covers a prototype, engineering validation build, pilot run, mass production, repeat order or transfer from another supplier. Provide the forecast, batch sizes and expected product life because a low-volume flexible probe strategy and a dedicated production fixture solve different commercial problems.
Use the same released inputs that will control manufacturing. At minimum, provide Gerber or ODB++/IPC-2581 data, netlist where available, BOM with complete orderable MPNs, pick-and-place data, assembly drawings, schematics, test-point information, mechanical interface files, firmware and programming package, product specification and applicable customer requirements. The GNS guide to files for a PCBA quotation gives the wider submission context.
Mark information that is preliminary. If schematic, firmware, connector pinout, enclosure, loads or test limits will change, require the supplier to identify assumptions, excluded work and the trigger for requotation. A quotation based on an unnamed draft revision creates a false price comparison and often transfers fixture rework, program debugging and schedule risk into the first build.
State the product and use-condition boundary
Describe the powered states and interfaces that manufacturing test may exercise. Include supply rails, current limits, start-up sequence, analog ranges, digital I/O, communication buses, sensors, actuators, displays, relays, motors, loads, calibration, safety interlocks and expected firmware state as applicable. Separate board-level behavior from functions that require an enclosure, antenna, mechanical load, external sensor, cloud service or final-system assembly.
For industrial or safety-related products, identify hazardous energy, high voltage, stored energy, thermal surfaces, moving outputs and safe-state requirements. The supplier needs this information to design guarding, interlocks, discharge, current limiting, operator steps and fault recovery. Do not assume that a functional specification written for a design laboratory is safe or efficient on a production line.
Comparable test quotations begin with one controlled product, revision and manufacturing baseline. Translate product risk into fault and behavior targets
Start with what must be detected, not with a list of machines. Manufacturing risks can include solder opens and bridges, wrong or missing components, polarity, placement, hidden-joint conditions, damaged connectors, incorrect values, power-rail faults, programming errors, calibration errors, interface failures and incomplete product functions. Product-specific risks can include timing, sensor accuracy, RF behavior, high-current switching, isolation, leakage or safe shutdown.
Build a coverage matrix that links each target to a method, access condition, limit, evidence and owner. A method can contribute to several targets, and one target may require more than one method. For example, AOI can confirm programmed visible features but cannot see every hidden joint. X-Ray can image selected hidden structures but does not prove every wetting, fatigue or powered function. ICT can detect accessible structural and component faults but depends on DFT and fixture access. FCT can exercise defined behaviors but can pass while an unexercised manufacturing fault remains.
Do not require every supplier to use the same method when the buyer’s actual need is a fault target and evidence outcome. An RFQ can define mandatory gates and invite an alternative proposal for the remaining risks. Require the supplier to map each proposed method to the target matrix and identify exclusions. The existing GNS explanation of AOI, X-Ray, ICT and FCT helps non-specialists distinguish those method boundaries.
Specify methods through conditions limits and evidence
A usable test requirement identifies the item under test, preconditions, applied stimulus, measurement or observation, numeric or coded limit, unit, tolerance, settling time, sequence, pass/fail logic and required record. If the requirement is functional, define the initial firmware and configuration, external loads, communication partners, calibration state and fault recovery. If the test is structural, define accessible nodes, component tolerances, guarded measurements and known exclusions.
Keysight’s official descriptions of in-circuit and functional testing illustrate why the methods answer different questions. The OEM should still approve product-specific targets and limits rather than copy generic equipment descriptions into an RFQ.
Control numeric limits and engineering margins
A nominal value is not a production limit. State the acceptable lower and upper limits, units, measurement point, instrument loading, fixture contribution and applicable environmental or warm-up condition. Explain whether the limit is a product requirement, manufacturing screen, diagnostic boundary or temporary NPI limit. Identify who may change it and what evidence is required.
Do not widen limits solely to remove false failures. First separate product variation, instrument uncertainty, fixture repeatability, contact resistance, software timing and operator effects. A limit review should preserve the original result, analysis, approved change, effective program revision and affected population. The RFQ should require the supplier to report unstable or high-guard-band tests rather than silently tune them during production.
Fault targets, operating states, measurement methods and numeric limits must be defined together. Quote fixture program and production support separately
Fixtures and programs are deliverables with their own lifecycle. Ask the supplier to separate non-recurring engineering from recurring unit cost. The NRE proposal should state fixture concept, board access, locating, connectors, pogo pins, actuation, guarding, instruments, switching, harnesses, test PC, software, licenses, reference units, documentation, acceptance trials, spares and expected maintenance.
Define who supplies the golden board, known-failure samples, mating cables, loads, external devices, calibration references and proprietary software. If the OEM provides a test sequence, specify the integration responsibility and whether the supplier may modify it. If the EMS provider develops the sequence, define source-code ownership, compiled deliverables, password and license access, backup, transfer rights and end-of-project disposition.
The quotation should identify assumptions that can change the fixture: PCB outline, tooling holes, test-pad size and location, connector type, enclosure access, panelization, firmware readiness, expected force, high-current paths and product variants. The comparison between ATE and flying-probe testing is useful when deciding whether dedicated production tooling is justified.
Fixture hardware, interfaces, software, maintenance and change ownership need explicit RFQ boundaries. Define fixture acceptance and ongoing readiness
Acceptance should challenge more than one passing board. Include mechanical fit, contact repeatability, protection, safe operation, known-good units, known-failure or simulated faults, limit challenges, repeat cycles, barcode and serial handling, data output, operator instructions and recovery from interrupted tests. Define the expected acceptance report and approval authority.
For production, identify preventive maintenance, probe and connector replacement, calibration status, self-checks, reference-unit control, spare parts, storage and troubleshooting ownership. Ask how the supplier will distinguish a product failure from a fixture, instrument, software or contact failure. Otherwise, a worn probe can create repeated retests while the dashboard still reports a final PASS.
Define sampling retries failures and release decisions
State which gates apply to every board, which use a defined sample, and which are NPI or change-triggered. Do not use “sampling per standard” without naming the agreed plan, lot definition, acceptance rule and response to a failure. A frequency requirement should connect to product risk, process capability, detection opportunity and customer or regulatory obligation.
Define retry rules before production. A communication timeout, operator loading error, fixture contact failure and product functional failure require different responses. Set the maximum automatic and manual attempts, the data retained for every attempt, conditions for reseating or restarting, escalation authority and the point at which the unit and affected population enter hold.
Preserve the first failure. The record should link the serial or board identity, work order, product and firmware revision, station, fixture, program and limits revision, timestamp, measured result or code, diagnostic finding, repair or disposition, impacted retest and final release. A last-PASS-only export hides process signals and cannot support an effective supplier or field investigation.
Require traceable outputs and controlled change
Attach a sample data schema or require one with the proposal. Decide whether the customer needs a summary, a per-board CSV, a database export, images, waveforms, measurements, failure logs or a signed report. State retention, access, naming, time zone, units, serial format and correction rules. The record should remain understandable without relying on a temporary dashboard view.
Control changes to the product, fixture, instruments, software, firmware, program, test sequence, numeric limits, sampling, diagnostics and data interface. Define which changes require notification, regression testing, new reference evidence or customer approval. The PCBA project review before quotation is the correct place to expose these dependencies before they become production exceptions.
Original failure, repair, retest attempts and final disposition must remain traceable as one evidence chain. Ask each bidder to return a requirements compliance matrix. For every line, the response should say compliant, compliant with assumption, alternative proposed or excluded. It should identify method, fixture, program, evidence, NRE, unit-cost impact, cycle assumption, required customer input and open decision. This makes the commercial comparison follow the technical obligation instead of comparing totals built on different scopes.
Run a quotation-readiness review before release
Before the RFQ leaves the OEM, have hardware, test, quality, NPI and procurement review the same matrix. Hardware confirms functions, interfaces, safe states and design access. Test engineering confirms stimuli, measurements, limits, software, fixtures and diagnostics. Quality confirms criteria, records, failure routing, sampling and release. Procurement confirms that NRE, ownership, capacity and recurring assumptions can be compared. Record unanswered questions rather than letting each supplier make a different assumption.
Ask bidders to identify the information date and revision used for their coverage estimate. If a supplier cannot estimate a requirement, the response should show the missing input, temporary assumption, cost or schedule range and closure milestone. This is more useful than a fixed price built on an unstated exclusion. For an early-stage product, quotation can proceed with ranges, but the contract should name the design-freeze and test-acceptance gates that convert those ranges into released obligations.
Review capacity as well as technical method. Compare expected test cycle, loading and unloading, programming time, diagnostics, repair demand, fixture quantity, instrument availability, maintenance, calibration and recovery from downtime. A technically complete sequence can still become a production bottleneck. Require the supplier to state which cycle estimate excludes retries, debug, firmware download or reporting, and how growth in volume or variants would be handled.
Finally, attach a deliverables checklist to the purchase decision. It should name the approved requirement matrix, fixture and program acceptance, operator instruction, preventive maintenance, calibration, reference units, source or compiled software rights, result schema, sample report, data retention, customer access, change procedure and end-of-project transfer. These items prevent the test system from becoming an undocumented dependency after the first successful build.
Conclusion
A useful PCBA test RFQ does not buy a machine name. It buys a controlled decision for a defined product configuration. Start with faults and behaviors, then assign complementary methods. State conditions and numeric limits, expose fixture and software ownership, preserve failures and retries, define the evidence package, and control every change that can alter the release result.
Before sending the RFQ, verify that a supplier can identify the board, revision, firmware, target, method, fixture, program, limit, result, attempt history and final disposition from the requested record. If the answer is unclear, the quotation will be unclear too. Provide the released design package and risk priorities, and require bidders to return assumptions and exclusions line by line.
Request an RFQ Test Requirement Review
FAQ
What PCBA test information should an OEM include in an RFQ?
Include the released product files, build stage and quantity, fault and function targets, required test methods, test access, fixtures, software and firmware, operating conditions, numeric limits, sampling or every-board rules, failure and retest handling, traceability fields, deliverable records, ownership and change-control requirements. Ask the supplier to return assumptions, exclusions, NRE and recurring-cost effects.
Is 100 percent functional testing a complete PCBA test requirement?
No. The statement identifies frequency but not the behaviors, interfaces, loads, limits, exclusions, sequence, equipment, fixture, software, evidence or failure disposition. Define what every board must demonstrate and which manufacturing risks require complementary visual, X-Ray or structural electrical checks.
Who should own a PCBA test fixture and program?
Agree ownership before quotation. Separate design authority, development cost, customer-supplied inputs, acceptance, maintenance, calibration, spare parts, source files, licenses, access rights, transfer, storage and end-of-project disposition. Ownership of hardware does not automatically provide maintainable software or complete design documentation.
How should failures and retests be specified?
Preserve the first failure, every attempt, diagnostic finding, repair or disposition, impacted retest scope and final release state. Define retry limits, operator actions, engineering escalation, approved rework, serial or lot traceability and conditions that block shipment. A final PASS must not overwrite the evidence needed to understand the original failure.
