Verification After Repair#

Replacing the faulty component is only half the job. The repair isn’t done until the circuit is confirmed working correctly — and confirmed not to have introduced new problems.

This page covers the general verification framework. For device-specific verification plans — full checklists tailored to a particular type of DUT — see the sub-pages below.

Before Power-Up#

Don’t just plug it in and hope. Quick checks before applying power can prevent a second failure.

1. Visual inspection — Look at the rework area under magnification. Check for solder bridges, cold joints, flux residue, and correct component orientation (especially ICs, diodes, and polarized caps)
2. Shorts check — Measure resistance across the power rail(s) near the repair area. Compare to the expected value — a dead short means something is still wrong. If this wasn’t measured before the repair, that’s a lesson for next time
3. Continuity check — Verify the new component’s connections are solid. Probe from the component pad to a downstream point on the same net

See Is voltage present? and Joint & Contact Integrity

Current-Limited First Power-Up#

A current-limited bench supply is ideal for the first power-up after repair.

1. Set the voltage to the correct supply voltage
2. Set the current limit to slightly above the expected normal draw (if known) or start low (50–100 mA for small circuits) and increase
3. Power on and watch the current reading
4. If current spikes to the limit immediately, power off — something is still shorted or drawing excessive current
5. If current is normal, proceed to functional testing

This simple step prevents a cascade failure where a botched repair destroys additional components on the first power-up.

See Is current draw expected?

Functional Test: Confirm the Original Fault is Fixed#

Test the specific symptom that started the debug session.

• If the board was dead → does it power up and run?
• If a signal was wrong → is it correct now?
• If it was intermittent → does the intermittent condition still trigger it? (This may require extended testing or environmental simulation)

Don’t just check “does it turn on” — verify that the original fault condition is resolved. If the symptom was “resets under load,” test it under load.

Regression: Did the Repair Break Anything Else?#

A repair can introduce new problems, especially if:

• Adjacent components were disturbed during rework
• A nearby part was overheated
• The board’s thermal characteristics changed (different component, added thermal mass)
• The original fault was caused by something that could damage multiple components

What to check:

• All functions, not just the one being repaired
• Adjacent circuits on the board
• Different operating modes (if applicable)
• If the board has multiple channels, check them all

Stress Testing#

Normal operation on the bench is the minimum bar. For a repair worth trusting, stress the board.

Not every repair needs every stress test. Match the stress to the failure mode — if the original fault was thermal, thermal soak is essential. If it was mechanical, the flex/vibration test matters most.

Confidence Levels#

Not all “working” is equal. Be honest about what has actually been verified:

“Boots”#

The circuit powers up and shows signs of life. This is the lowest bar — it means power is probably okay and the processor (if any) is running, but not much else has been verified.

“Stable”#

The circuit passes functional tests under normal conditions. The original fault is gone, and basic operation is confirmed. Most bench repairs stop at this level.

“Reliable”#

The circuit passes functional tests under stress conditions (temperature, load, vibration, extended run time). Enough testing has been done to trust it in its actual operating environment. This level requires deliberate stress testing — it can’t be reached by running the board on the bench for five minutes.

Be explicit about which level has been reached when declaring a repair “done.” If it’s only at “boots,” say so — don’t assume stability.

DUT-Specific Verification Plans#

The general framework above applies to any device, but each repair should have a verification plan tailored to the specific device — what to measure, in what order, and what the pass criteria are. Develop and record this plan alongside the repair project itself, where the device-specific context lives.

Cross-References#

• Power verification: Is voltage present?
• Current draw: Is current draw expected?
• Intermittent connection testing: Intermittent Connection