XJTAG Insights
Posts
Why PCB testing needs to shift left to the design stage

Why PCB testing needs to shift left to the design stage

Matthew Holder - Hardware Engineer
March 25, 2026

Hi reader!

Rather than being designed in from the start, PCB testing is often something bolted on at the end of a design as an afterthought. Yet too many PCB faults are only discovered at the release stage or in the field. By then the cost of correcting those faults is much higher, involving rework, scrapped boards, missed deadlines, and damaged customer trust.

Conversely, designing with testability in mind from the beginning reduces these risks by turning otherwise hidden problems into predictable checks that are simple to automate. Often called shift-left testing, it moves test considerations back along the development pipeline into the schematic, PCB layout, and design reviews rather than waiting until prototypes or production.

This early test planning lets you ensure nets are accessible, choose appropriate test connectors, reserve test points, and partition subsystems so faults can be isolated quickly. It also makes production tests faster and more deterministic, shortens debug time during bring-up, and gives support engineers clear diagnostics when failures occur in the field.

A shift-left mindset doesn’t prescribe a single method, however. Instead, it means embedding test requirements into the design so you can later apply the right mix of structural, functional, and automated tests. By integrating testing into the design process, failures can be traced back to their root causes rather than leaving you chasing symptoms later. Put simply, the earlier you plan how to test a board, the fewer surprises you’ll face down the line, reducing testing costs, shortening the time to market, improving product quality, and enhancing fault detection at every stage.

Figure 1 – Moving to a Shift-Left testing approach

Practical ways to track test requirements

Ensuring that test requirements remain visible and aligned with design starts with a disciplined approach to documentation and configuration control. One effective method is to maintain dedicated test plans and procedures in version‑controlled repositories. By keeping project files, fixture lists, and pass/fail criteria with a clear document ID and revision history, teams can avoid ambiguity and ensure that everyone is working from the same baseline.

Version control also plays a critical role in managing test repositories. Storing scripts, firmware, and project data in source control keeps test assets synchronized with board revisions, reducing the risk of mismatches between hardware and software.

Equally important is linking test artefacts directly within product lifecycle management (PLM) systems. When test plans and results are attached to the product record, design revisions and test requirements remain connected and auditable, preventing the disconnect that often arises between engineering and manufacturing.

For design reviews and Design for Testability (DFT) sign‑off, many teams rely on a testability matrix. This structured mapping of modules, nets, and components to expected coverage and methods, like associating a power rail with ICT or a bus with boundary-scan, makes test coverage explicit and easy to communicate.

On the production side, test steps should be embedded in the manufacturing bill of materials (MBOM) or shop‑floor work orders, rather than in engineering‑only files. This ensures that test routing and operations are documented where process details belong, making test execution part of the standard workflow.

Integration with test management or Manufacturing Execution System (MES) tools adds another layer of traceability. Assigning test IDs, controlling which version each board should run, and capturing results centrally allows analytics to be performed across the product lifecycle, strengthening confidence in the data.

Finally, linking test issues to Engineering Change Orders (ECOs) ensures that lessons learned are not lost. By tying failures to corrective actions, design rules and future test plans are updated in response to real‑world experience.

These methods keep design and procurement artefacts clean while ensuring test requirements remain discoverable, traceable, and under configuration control – which is the whole point of shifting test planning left: including it from the start.

Common pitfalls: Case studies from the field

The value of shift-left test design becomes obvious when you look at common failure modes. The following real-world examples show how seemingly minor oversights can block testing and drive up costs across manufacturing and field service.

Missing boundary-scan access for power sequencing

Symptom:
During manufacturing test, the board fails to power up consistently. As a result, the JTAG boundary‑scan chain cannot initialize, and downstream structural tests are blocked.

Detection:
During bring-up, structural JTAG tests fail to run. Investigation shows the device never enters boundary-scan mode because its rails are not enabled in the correct order. Manual jumper wiring of the rails allows partial testing, confirming the sequencing dependency.

Root cause:
Power sequencing for key rails is controlled by a device that itself requires boundary-scan mode for configuration. However, no provision is made in the design to allow external control or override of the power supplies. As a result, the scan chain remains inaccessible at startup.

Design lesson:
Always design an external override or bypass path for power sequencing so that test equipment can force rails on independently. Boundary-scan access is only useful if the scan chain can be reached – power domains and enable signals must be testable without relying on the devices under test.

Compliance pins not considered for boundary-scan entry

Symptom:
The JTAG chain does not initialize, and devices are reported as absent or stuck in BYPASS.

Detection:
During prototype testing, boundary-scan does not detect several expected devices. Pin-tracing in the schematic reveals that some compliance pins are pulled to incorrect logic levels and lack any board-level access to override them during test.

Root cause:
Compliance pins on a key IC are neither connected out to test pads nor tied to the correct logic levels, preventing the device from entering boundary-scan mode. With one device stuck, the whole chain becomes inaccessible.

Design lesson:
Designs must treat compliance pin handling as a first-class DFT requirement. Their expected states should be documented, correct pull-up/pull-down resistors must be in place, and accessible pads or jumpers should be provided where overrides may be required. Missing these simple connections can block the entire JTAG chain.

Inaccessible TAP location on server board

Symptom:
Field diagnostics require disassembly of production servers, adding time to troubleshooting and increasing service cost.

Detection:
Service technicians report extended turnaround times for boundary-scan diagnostics. The mean time to repair (MTTR) is significantly higher than forecast because even simple checks require a major system teardown.

Root cause:
The Test Access Port (TAP) is placed mid-board for convenience during layout but is not routed to an accessible connector on the front or rear panel. This means every in-field boundary-scan or firmware test requires removing covers, boards, and cabling.

Design lesson:
Designs must consider service and field-test access during layout. TAP headers should be placed at the chassis edge, or JTAG signals brought to accessible connectors, even if not populated in production. The minor cost of adding a connector footprint is far outweighed by the recurring operational cost of inaccessible diagnostics.

Conclusion

Shifting test planning left isn’t just about avoiding rework, it’s about building confidence into every stage of the product lifecycle. The cost of a few extra pads, connectors, or overrides is tiny compared to the recurring cost of inaccessible or incomplete testing later. By embedding testability at the design stage, you can reduce costs, accelerate schedules, and ensure more reliable products reach your customers.

Ready to apply shift-left testing in practice?

Build robust test coverage and improved efficiency in
your next project from day one.

Got questions or suggestions for future topics? Please get in touch and let us know.

If you enjoyed this update, please forward to a colleague who may find it interesting.