PCBA test coverage planning connects each relevant failure mode to a test operation, its evidence and its remaining limitations. Start with a defined set of faults and requirements. Then document which checks can detect each condition on the actual assembly. A percentage without a denominator, test configuration and treatment of overlapping checks is not enough to compare proposals.
This guide describes a coverage review for engineers and buyers planning an assembly build. It does not assign universal detection rates to ICT, optical inspection, boundary scan or functional testing. The worksheet and numerical example are planning aids, not measured performance, a reliability prediction or a claim about equipment available at this company.
Define what the coverage claim includes
Separate three questions. Does a test reach the relevant node or interface? Does its stimulus and observation distinguish the fault from an acceptable condition? Has that detection claim been demonstrated for the released setup? A reachable node can still lack a meaningful test. A test that passed a known-good board has not necessarily demonstrated that it rejects the fault under discussion.
Write the fault universe before calculating a score. It might include selected assembly defects, incorrect fitted variants, missing firmware configuration or specified functional failures. State exclusions explicitly. A board-level assembly-defect analysis and a product-level functional requirement matrix can both be useful, but their counts should not be mixed into one unexplained percentage.
Separate component, connection and product behavior
XJTAG’s explanation of PCOLA/SOQ separates device-related attributes from connection-related faults and explains why results from multiple methods should not simply be added. It also describes weighted and partial coverage. Use the scoring convention agreed for the project; do not apply a tool’s score as if it were the probability that every shipped board will be reliable.
For practical review, keep the individual finding visible behind the total. A component may be present and electrically active while an unexercised function remains unchecked. A product might complete a basic communication exchange without exercising all connector contacts or operating modes. The coverage record should name the tested condition rather than describing the entire component as “tested.”
Build a failure-mode-to-test matrix
This example structure uses questions rather than assumed detection capabilities. Replace the illustrative fault descriptions with those relevant to your assembly and have the test owner complete the evidence column.
| Potential condition | Proposed check to evaluate | Evidence or limitation to document |
|---|---|---|
| Wrong fitted component | Material identity review plus an appropriate inspection or electrical check | Which characteristic distinguishes the wrong part from the approved one? |
| Open connection | A connection test using the available access and circuit configuration | Can parallel paths or unexercised pins conceal the condition? |
| Unintended short | A targeted isolation or electrical check | Which possible node pairs are included, and which are excluded? |
| Incorrect programmed variant | Readback, identity or behavior check defined for the device | Does the result identify the configuration actually released for this product? |
| Output outside a requirement | A functional measurement with defined stimulus and loading | What operating conditions and acceptance limits apply? |
| Intermittent connection | A product-specific investigation and approved verification method | What conditions were exercised, and what intermittent behavior remains untested? |
| Unassessed fault | No approved method yet | Keep it open with an owner; do not silently count it as covered |
Include a stable identifier for each row. Connect the row to a requirement, reference designator, net or interface as appropriate. Record the test step and version that supply its evidence. This lets a reviewer determine which claims need reconsideration when the layout, BOM, firmware or test program changes.
Example: why two percentages cannot simply be added
Assume a hypothetical review contains 100 equally weighted, explicitly listed fault conditions. Method A has accepted evidence for 60 conditions. Method B has evidence for 45 conditions, of which 30 are already in A’s list. The distinct covered count is 60 + 45 − 30 = 75, so the coverage of this defined list is 75/100 = 75%.
This is an illustrative planning calculation only. It is not a PCOLA/SOQ implementation or a measured fault-detection probability. It assumes binary coverage decisions and identical denominators. Partial credit, different weighting or different fault universes require the agreed scoring rules. The remaining 25 conditions still need disposition even if the combined total appears satisfactory.
A useful purchasing question follows: which additional conditions does the proposed second method address? The answer should identify rows and evidence. “More testing” alone does not explain whether the extra operation closes a meaningful gap or repeats an already covered observation.
Validate the setup behind the claim
Define an approved method to challenge important detection claims. The engineering team might use controlled reference assemblies, simulated conditions or another documented approach appropriate to the test. Do not damage production stock or introduce unsafe faults merely to populate a checklist. Record the challenge, expected response, actual result and any limits on what the experiment establishes.
Keep the test configuration reproducible. NI’s TestStand deployment guidance identifies dependencies beyond a sequence file, including code modules, framework files and drivers or runtimes. That is an equipment-specific example of why a released test package needs its supporting configuration. This article does not require TestStand or imply that a particular platform is used here.
Record gaps, retests and release ownership
Give each uncovered condition an owner and a proposed disposition: add a check, change access, revise the design or explicitly accept a documented limitation through the project’s approval process. Keep the original test failure when a board is retested. A later pass should remain connected to any repair, fixture adjustment or configuration change that preceded it.
Ask whether a reported figure describes planned, implemented or demonstrated coverage. These are different stages of evidence. Record the board and software revisions to which the result applies, and identify changes that require reassessment. A summary can then be traced back to specific decisions rather than used as a general assurance.
What to include in a test-scope inquiry
For a PCB testing proposal, provide the schematics, BOM variants, available access, functional requirements, firmware information and any existing test assets. Attach the draft coverage matrix with its open items. Use the quality and acceptance requirements review to agree on evidence and responsibilities.
When comparing an electronic manufacturing service, compare the same fault universe, operating conditions and exclusions. That makes differences in proposed test scope visible before price becomes the only comparison.