Don’t Throw Away the Tests That Got Your Prototype Working

Simon Payne, CEO, XJTAG | October 13, 2026 Subscribe to LinkedIn newsletter

The first prototype arrives and the engineering team begins the process of proving the hardware.

Connections are checked.

Memories are exercised.

Peripherals are tested.

Problems are found, understood and fixed.

Eventually, the board works.

And then something slightly strange can happen.

Much of the test capability that helped get it working is never used again.

Bring-Up Creates More Than a Working Board

During bring-up, engineers build up a significant amount of knowledge about the hardware.

They learn how to initialise devices.

They discover which signals need to be controlled.

They find ways of checking memories and peripherals.

They work out how to distinguish between a software problem and a hardware problem.

Sometimes this knowledge becomes a formal test.

Sometimes it is a small utility written by one engineer.

Sometimes it is little more than a sequence of commands, measurements or notes that helped prove a particular part of the board.

But whatever form it takes, it has value.

The question is:

What happens to it once the prototype works?

A Test Shouldn’t Necessarily Be Used Only Once

Some bring-up tests are naturally temporary.

But many aren’t.

If a test helped prove that an interface was correctly connected on the first prototype, there may be no reason why the same test cannot help verify that interface again later.

The purpose simply changes.

During bring-up, the question might be:

“Did we design this correctly?”

During production:

“Has this particular board been assembled correctly?”

During repair:

“Which part of this board is no longer behaving correctly?”

Different stages of the product lifecycle.

But often the same underlying hardware evidence is useful.

Turn Engineering Knowledge into Something Repeatable

There is an important difference between knowing how to test something and having a test that someone else can run.

If an engineer manually performs a sequence of checks during bring-up, that knowledge may disappear when the project moves on.

If the same procedure is documented and automated where practical, it becomes reusable.

That means the effort invested during development can continue providing value.

Instead of every new team starting again, the product carries some of its diagnostic knowledge with it.

Boundary Scan Is Particularly Well Suited to Reuse

Boundary Scan can be especially useful here because structural tests are based on the hardware and its connectivity rather than depending entirely on the final application software.

A test created to verify connections between devices during bring-up can potentially verify those same connections during manufacturing.

A test used to exercise a memory, peripheral or other accessible device may remain useful during fault diagnosis.

The reason for running the test changes.

The physical hardware being checked does not.

That gives structural tests the potential to move with the product from development into production and later support.

Don’t Lose the Tests at Handover

When a product moves from development into manufacturing, the handover typically includes things such as:

Schematics
PCB data
BOMs
Manufacturing information
Firmware
Programming files
Test specifications

It is worth asking whether the diagnostic capability developed during bring-up should be treated in exactly the same way.

Which tests proved particularly useful?

Which interfaces can be independently verified?

Which procedures helped isolate previous faults?

Which tools or scripts should be retained?

If that knowledge stays with one engineer rather than moving with the product, its value can easily be lost.

One Investment, Several Uses

The same test capability can potentially support:

Prototype bring-up — establishing confidence in the first hardware.

Design verification — proving that important areas of the PCB behave as intended.

Production — checking whether individual assemblies have been manufactured correctly.

Repair and rework — confirming whether a fault has been successfully corrected.

Failure analysis — narrowing down where to investigate a returned board.

Long-term support — providing engineers with diagnostic capability years after the original development team has moved on.

That starts to change the way we think about the cost of developing a test.

It isn’t necessarily an investment for one stage of the project.

It can be an investment in the product’s entire lifecycle.

Where XJTAG Fits

This is one reason an XJTAG project can become more than something used to bring up the first prototype.

Once the design information, device models and tests have been developed, that work can potentially be reused as the product moves into manufacturing, repair and support.

Rather than rebuilding the test strategy at every stage, the same underlying project can evolve with the hardware.

The value isn’t simply in running another test.

It is in preserving and reusing what the engineering team has already learned.

Closing Thought

Getting the first prototype working shouldn’t necessarily be the point at which your test investment ends.

It can be the point at which that investment starts becoming reusable.

The tests that help an engineer understand board number one may also help manufacturing verify board number 1,000—or help a service engineer understand a failure years later.