A PCB assembly test coverage matrix lists a defined set of fault conditions, identifies which enabled tests have evidence of detecting each condition, and exposes overlaps and gaps. Calculate coverage by counting distinct covered conditions and dividing by the total number in that defined set—not by adding coverage percentages from separate tests.
The matrix is useful only in its revision context. A result for one board revision, test program, fixture and operating condition may not apply after a design or process change. A test pass also does not guarantee that an assembly is defect-free or reliable in service.
If you are still choosing methods, start with boundary scan, flying probe and functional test selection. The ICT testing guide explains one method in more detail. This article addresses a different deliverable: the cross-method artifact that records what the selected tests cover, how that coverage is supported, and what remains uncovered.
Define what “coverage” means
A coverage percentage without a numerator, denominator and scope is difficult to interpret. Several useful measures are often confused:
| Measure | What it counts | What it does not establish |
|---|---|---|
| Physical net access | Nets with usable probe access out of a defined eligible net set | That every accessible net has an effective electrical test |
| Component inclusion | Components included in enabled tests out of an in-scope component set | That every relevant fault on each included component is detectable |
| Fault-model coverage | Distinct modeled fault conditions with credited detection out of the defined fault universe | Detection of faults outside that universe or field-failure probability |
| Inspection coverage | Defined features or inspection conditions examined out of the inspection scope | Electrical operation or hidden-joint quality unless specifically observable and validated |
| Functional requirements coverage | Requirements or operating states exercised under specified conditions out of the selected requirements or states | All possible faults or all real-world operating conditions |
| Reliability validation | Evidence about performance under defined stresses, durations and conditions | A direct substitute for production defect coverage |
For example, a test point may make a net physically accessible, but circuit topology, parallel paths, probe contact, test limits or disabled routines can still prevent a useful measurement. The PCB test points guide discusses access planning; the matrix must go further and connect that access to a specific detectable condition.
Similarly, an AOI program may inspect a component’s presence and polarity without establishing whether it works electrically. IPC’s IPC-A-610, Acceptability of Electronic Assemblies is an example of an assembly acceptance document; the applicable edition and criteria still need to be agreed for the project. An inspection acceptance criterion is not, by itself, a quantified cross-method fault universe.
Select methods for observable conditions
Each method has a different observation point. The table below is a planning aid, not a promise that any particular system or procedure will detect a particular defect.
| Method | Potential contribution | Important qualification |
|---|---|---|
| SPI | Inspects defined solder-paste print features before placement and reflow | Paste measurements are not direct proof of the final solder joint. Credit for a modeled condition needs an applicable procedure and evidence. |
| AOI | Inspects visible features such as presence, orientation and some solder-joint conditions | Visibility, lighting, programming, component geometry and acceptance criteria matter. Hidden features may not be observable. |
| X-ray inspection | Examines features hidden from optical view, including some solder structures under packages | Detectability depends on the defect, geometry, equipment and inspection procedure. An image is not automatically an electrical or reliability test. |
| ICT | Can test accessible nets, shorts and selected component characteristics using a defined fixture and program | Probe access, circuit topology, isolation, limits and enabled tests constrain coverage. |
| Flying probe | Can make programmed electrical measurements on accessible locations without a dedicated bed-of-nails fixture | Probe reach, test sequence, circuit effects and the applicable procedure still limit what can be measured. |
| Boundary scan | Can exercise or observe supported connections through a configured scan chain | Suitable devices, chain access, board state, device descriptions and test vectors are needed; it does not automatically inspect every internal joint or circuit. |
| Functional test, or FCT | Exercises specified board functions under defined inputs, loads and states | A passing function demonstrates only the conditions and acceptance limits actually exercised. |
Boundary scan uses a test access architecture to exercise or observe supported connections; whether a particular board can use it effectively remains a design and procedure question. Confirm the applicable standard and edition for the project.
For method-specific planning, see solder paste inspection, PCB X-ray inspection and PCB functional testing. None of these methods has a universal coverage percentage that can be transferred to a different assembly without defining the universe and evidence.
Build the fault universe before counting
A fault universe is the list of conditions the coverage calculation will consider. Each row should describe one distinguishable condition with enough context to decide whether a test can detect it.
A useful row identifies:
- Fault ID and location: component reference, net, joint, circuit or functional requirement.
- Condition: for example, an open at a specified resistor terminal or a power-up failure at a specified input and load.
- Scope and assumptions: board and BOM revision, operating state, access and whether the model assumes a single fault.
- Candidate methods: tests that might observe the condition.
- Credited detection and evidence: the enabled test and the evidence supporting that mapping.
- Disposition: covered, conditionally covered, unvalidated or uncovered, with an owner for any action.
The fault list may include both physical defects and defined functional failures, but state that scope explicitly. Avoid vague rows such as “bad solder” or “power fault”: they can conceal several different mechanisms and observation conditions.
A row is a modeled condition, not necessarily an independent physical event. One underlying defect might cause more than one listed symptom, and several defects may occur together. If the model assumes one fault at a time, record that assumption; simultaneous faults can mask or change test responses.
For comparisons between revisions or suppliers, keep the denominator and definitions consistent. A larger percentage from a narrower universe is not necessarily better coverage.
Worked example: count the union, not the percentages
Assume a hypothetical assembly has the following eight in-scope fault conditions. For this illustration, AOI and ICT detection mappings are already validated for the specified board revision, enabled programs and applicable conditions. This is arithmetic, not a report of actual lab results.
| ID | Defined modeled condition | AOI credited | ICT credited |
|---|---|---|---|
| F1 | A visibly marked polarized component is installed reversed | Yes | No |
| F2 | Component C1 is absent | Yes | No |
| F3 | A specified resistor terminal is visibly open, with an electrical open detectable by the ICT procedure | Yes | Yes |
| F4 | Resistor R2 is absent | Yes | Yes |
| F5 | Two specified nets are shorted beneath a package, with access elsewhere for the ICT measurement | No | Yes |
| F6 | R3 has the specified wrong resistance, detectable by the ICT measurement despite the circuit’s parallel paths | No | Yes |
| F7 | A specified hidden BGA connection is open | No | No |
| F8 | The supply fails to start at a specified input and load | No | No |
“No” means no detection credit in this example. It does not assert that the method could never detect that condition on another board or with another validated procedure.
The denominator is eight distinct modeled conditions:
- AOI detects F1, F2, F3 and F4: 4/8 = 50%.
- ICT detects F3, F4, F5 and F6: 4/8 = 50%.
- F3 and F4 are shared detections: 2 conditions.
- The union is F1 through F6: (4 + 4 − 2)/8 = 6/8 = 75%.
- F7 and F8 remain uncovered by this credited AOI-and-ICT combination: 2/8.
Adding 50% and 50% would double-count the shared conditions. Multiplying the percentages would not calculate the union either; no assumption has been made that faults or test outcomes are independent.
Each modeled condition has equal weight in this calculation. The 75% figure is not actual statistical test effectiveness, a design-verification result or the probability that a unit will avoid a field failure. F7 and F8 may also have different severities from the covered conditions. A team may therefore prioritize them even though each contributes only one row to the count.
The next step is to investigate a suitable observation method for each gap. For example, assess whether an X-ray procedure can detect the defined F7 condition, or whether an FCT procedure can exercise the defined F8 startup condition. Do not change either row to “covered” merely because a method sounds suitable; validate its detectability for the relevant assembly and procedure.
Record evidence, conditions and sampling
A practical matrix distinguishes a test that is merely planned from one that earns detection credit. For each credited cell, retain a reference to evidence appropriate to the project, such as:
- The enabled test step, inspection rule or functional sequence and its revision.
- The applicable board, BOM, fixture, software and configuration revisions.
- The defect representation or test condition used to evaluate detectability.
- Expected and observed indications, acceptance limits and relevant known-good behavior.
- Limitations, such as visibility, access, parallel paths, power state or operating temperature.
- The responsible reviewer and evidence status.
The credibility of a mapping depends on how representative the evidence is. A program listing alone shows that a test exists; it does not necessarily show that the test detects the modeled fault. Conversely, a single demonstration may not establish detection across every variant or process condition. Record the extent and confidence of the evidence rather than implying more than it supports.
Disabled tests do not earn current coverage credit. A test may also be conditional: for example, it may require a particular fixture, installed option, firmware state or scan-chain configuration. Document the prerequisite and show which production route satisfies it.
Sampling changes how coverage applies. If every unit receives ICT but only selected units receive X-ray inspection, the X-ray mapping applies to the inspected units or the defined sample—not automatically to every board in the lot. Record the population, selection rule and actual route. Similarly, SPI occurs before reflow; a print-stage finding and its correction should be traced through the process rather than treated as proof that the final joint passed an electrical test.
For a per-unit union, combine only the credited methods actually applied to that unit under their validated conditions. Record failures, repairs and retests separately so the final disposition can be understood.
Use the matrix to close gaps
Once the initial matrix is complete, review uncovered and conditional rows against their risk. The decision is not always to add another test: it may be to change the design for access, refine the procedure, add a process control, validate an existing method or accept a documented residual risk.
A useful gap record includes:
- The uncovered condition and affected variants.
- Potential impact and the basis for its risk assessment.
- A proposed detection, prevention or mitigation action.
- The action owner, target decision and evidence needed.
- Approval or waiver status, including any agreed limits.
Risk assessment should not be disguised as the equal-weight coverage percentage. A rarely modeled but severe power fault may deserve more attention than several readily detected cosmetic conditions.
Reassess affected rows when the board layout, component substitution, paste process, test access, fixture, inspection program, firmware or acceptance limits change. The extent of revalidation depends on the change and the agreed controls. Preserve the prior matrix revision so that coverage claims remain traceable to the assemblies and programs to which they applied.
Specify the artifact in the release package or RFQ
The matrix is most useful when responsibilities and deliverables are agreed before production release. Include the following fields in a request for quotation or test-planning package:
| Field | Information to provide or agree |
|---|---|
| Assembly identity | Board revision, BOM revision, approved variants and relevant component alternatives |
| Data and access | Drawings, netlist, test-point information, accessible sides, mechanical restrictions and applicable interface documentation |
| Fault scope | Fault universe, exclusions, single- or multiple-fault assumptions, and any functional requirements or states in scope |
| Methods and route | Proposed inspection and test steps, sequence, conditions, sampling and which units receive each step |
| Evidence | Required mapping confidence, validation approach, evidence references and treatment of unvalidated or disabled tests |
| Results | Required matrix format, numerator and denominator, overlap, uncovered rows, test results and traceability |
| Change and disposition | Revision control, revalidation triggers, repair and retest rules, gap owners and waiver authority |
| Acceptance | Applicable inspection criteria, test limits, functional requirements and responsibility for final release decisions |
The design owner typically has the information needed to define design intent and functional requirements. The test developer needs to map and validate executable tests. The manufacturing and quality teams need to control the actual process route, records and dispositions. Procurement can make the requested evidence and handover explicit in the commercial agreement. Assign these responsibilities for the project rather than assuming that a supplier’s quotation includes every activity.
For an assembly discussion, review the SMT assembly service, then provide the relevant revision and coverage requirements through the quote request. Use contact to clarify the proposed scope, evidence and responsibilities. Any test capability or deliverable should be confirmed in the project agreement.
Frequently Asked Questions
Is 100% fault-model coverage a guarantee of quality?
No. It means every condition in the defined universe has credited detection under the stated assumptions. Unmodeled defects, limited evidence and conditions outside the test scope can remain.
Can physical test-point access be used as fault coverage?
Not by itself. Access is a prerequisite for some electrical tests; effective detection also depends on the circuit, test procedure, limits and enabled program.
How should disabled tests appear in the matrix?
Keep them visible, but do not count them as current detection coverage. Record why they are disabled and what is required to restore and validate them.
Can inspection and electrical-test percentages be added?
Not without accounting for overlap and a common denominator. Count the distinct conditions covered by the actual combination of tests.
Who approves an uncovered fault?
The project agreement should assign that authority. The relevant design, quality, manufacturing and procurement participants should have the gap and its residual risk documented before disposition.