PCB Testability Guidelines
Decide what the finished board must prove, then design the access and test sequence to produce that evidence.
- Define the failures
Connectivity, assembly faults and functions
- Provide the access
Probes, connectors and supported test interfaces
- Control the verdict
Limits, firmware, sequence and traceability
A reachable test point is only the beginning.
Design for test connects the expected faults and functions to a practical test method. Physical-access testing and boundary scan can complement one another; their coverage depends on the circuit, available access and implemented test program.
Create a coverage matrix before final placement. For each critical requirement, identify the method, access, stimulus, expected response, decision limit and retained record. An untested requirement should remain visible—not disappear behind a generic “tested” label.
- Structural test
- Evaluates specified assembly or connectivity faults using an appropriate method.
- Functional test
- Exercises defined operating behavior under specified conditions and limits.
- Coverage gap
- A relevant fault or requirement not addressed by the selected test sequence.
What to resolve before release
Use these review prompts with the actual design, component documentation and agreed manufacturing process.
Start with a risk-to-test matrix
List the failures that matter to the product: shorts, opens, wrong parts, programming errors and missing functions. Assign each to a method and identify requirements that need engineering development.
Make physical access usable
Agree probe targets, finish, solder-mask openings, spacing and keepouts with the test/fixture team. Review access on the populated and possibly coated board—not only on the bare-board artwork.
Support the board during contact
Review probe forces, component height and fixture supports. Keep the fixture from stressing fragile components or contacting exposed conductors unintentionally. Decide how orientation and seating will be verified.
Design supported digital test access
Boundary scan uses device test logic and a test access port for supported operations. Review the actual devices, chain, power domains and required design information rather than assuming every IC is testable through JTAG.
Release programming as controlled data
Record the firmware image, version, checksum, interface and verification sequence. Define how unique identifiers and calibration values are generated, protected, checked and recorded.
Specify the test verdict and records
Document startup conditions, stimuli, loads, tolerances, timeout behavior and retest rules. Record enough information to link a result to the assembly revision, test-program revision and relevant serial or lot identity.
Choose complementary methods, not interchangeable labels
Typical roles are summarized below. Actual detection and coverage depend on the equipment, access, package and test implementation.
On a small screen, scroll the table horizontally to see every column.
| Method | Typical role | Important limit |
|---|---|---|
| Visual inspection / AOI | Evaluate accessible component and assembly features. | An optical view does not reveal every hidden joint or prove product function. |
| X-ray inspection | Evaluate selected internal or hidden-joint features. | Images alone do not demonstrate every electrical or functional requirement. |
| In-circuit testing (ICT) | Use the implemented test program and physical access to evaluate specified circuit/assembly faults. | Access, circuit interactions and test design constrain coverage. |
| Flying-probe testing | Apply programmed electrical checks at accessible targets. | Coverage and throughput depend on accessible nodes and test strategy. |
| Boundary scan / JTAG | Use supported device logic to improve access to selected interconnects and test operations. | Requires compatible devices and a usable chain; not a universal functional or high-speed compliance test. |
| Functional testing (FCT) | Exercise defined product operations with controlled inputs and limits. | Passing selected functions does not prove every joint or every operating condition. |
Keep the approved project requirements in control. Record uncertainties, agreed exceptions and the supporting evidence before the affected operation is released.
A test specification should make a repeatable decision.
Give the test developer a controlled schematic/netlist, expected behavior and explicit limits. Resolve prerequisites such as firmware loading, safe power sequencing, fixture engagement and calibration. The specification should explain what happens when a board fails, not just how a passing board looks.
- Control the setup
- List fixture revision, supply/load configuration and any calibration requirements.
- Control the sequence
- Define programming, test, coating and final-assembly order.
- Control the record
- Link outcomes and diagnostic information to the actual hardware and software configuration.
Move from open questions to controlled decisions.
These steps organize a project review. They do not replace your formal release or acceptance process.
Map
Connect product risks to test requirements.
Allocate
Reserve physical and supported digital access.
Develop
Release the fixture, program and decision limits.
Review
Evaluate failures, coverage gaps and change impact.
Record the review.
Keep the evidence.
12 checks for this topic. Record status and notes, then export a text copy for your project discussion. A completed checklist is not certification or production approval.
Session only. Nothing is saved automatically or transmitted. Export before closing or reloading. “Reviewed” records evaluation—not a pass verdict. Explain blocked and not-applicable items in the notes.
Showing 12 of 12 checks. Export always includes all checks.
Critical faults and functions are mapped to test methods.
State the requirement and the evidence needed.
Known coverage gaps are recorded and dispositioned.
Do not infer coverage from the test name alone.
Hidden joints have an inspection/test strategy.
Include the limitations of each method.
Probe targets and keepouts are agreed with the fixture team.
Review the populated board and target finish.
Fixture support and contact forces are reviewed.
Include height, polarity and safe seating.
Programming and supported JTAG access are available.
Verify device support, chain and voltage domains.
Power, loads and startup conditions are defined.
State safe sequencing and abnormal-condition handling.
Expected results and decision limits are released.
Include timing, tolerances and measurement uncertainty where relevant.
Firmware and calibration data are controlled.
Record version, checksum and unique-data handling.
Each result identifies the hardware and test revisions.
Include serial or lot identity as required.
Failure, rework and retest rules are documented.
Preserve diagnostic evidence and disposition history.
Quote scope includes the agreed test-development work.
Separate fixture/program development from routine testing.
No checks match these filters. Change a filter to view other items.
Export your checklist and resolve outstanding items with your engineering team before production. Confirm any changes through your normal approval process.
Practical answers
before release.
Use these answers to frame the discussion. The approved project requirements remain the authority for the build.
Do I need a test point on every net?
Set access requirements from the selected coverage strategy. Physical probes, supported boundary scan and connector-level tests may serve different needs. The decision should be made by the design and test teams rather than by a blanket rule.
What size should a probe pad be?
Confirm target dimensions, finish, spacing and keepout requirements with the chosen fixture and test process. Include the populated board and any coating or solder exposure; there is no universal dimension specified here.
Can JTAG test a board without physical access?
It can reduce the need for physical access to some interconnects when the relevant devices and chain support the operation. Access to the test interface, correct device information and a valid test implementation are still required.
Does passing FCT mean every solder joint is acceptable?
No. A functional test exercises the conditions and behaviors that were implemented. Workmanship evaluation and structural testing may address failure modes that the selected functional sequence does not expose.
Are fixture development and programming included automatically?
Do not assume they are. Define the required hardware, firmware, test software, development ownership and records in the project scope before requesting a production quote.
Technical references & scope
- Keysight — Requirement for Successful Boundary Scan Test Development on i1000D In-Circuit Test System (PDF)
Complementary physical and boundary-scan test access.
- JTAG Technologies — boundary-scan fundamentals
TAP access, embedded test logic and connectivity testing.
- Texas Instruments — SMT and packaging application notes
Starting point for the application note appropriate to the actual package.
- IPC Standards — official revision register
Document names, revision history and addendum compatibility; checked 28 September 2026.
Use these engineering references alongside your component documentation and the standards specified for your order. Share your completed checklist with us to confirm assembly, testing and material requirements.