Reduce No-Fault-Found (NFF) in Testing

No-Fault-Found is a returned unit that tests good on the bench. Nothing reproduces, so the unit ships back into service, often to fail again weeks later. Across component maintenance, NFF accounts for a large share of returns, and every one of them burns bench time while eroding trust in the test itself. This guide explains what NFF is, why it happens, and how to catch the pattern behind it using your own test data.

What No-Fault-Found Means

A unit comes off equipment reported as faulty. On the bench it passes every check. With no failure to act on, the unit is returned to service as serviceable. That is an NFF, sometimes logged as CND (Cannot Duplicate) or RTOK (Retest OK).

NFF is not one problem. It is a label for several:

• Intermittent faults. The defect is real but only appears under conditions the bench does not reproduce (temperature, vibration, a specific input sequence).
• Test escape. The bench limits are too loose, so a marginal unit passes.
• Wrong removal. The fault was elsewhere in the system, and a good unit was pulled.
• Fixture drift. The bench itself has changed, so a real fault reads as a pass.

You cannot fix what you cannot see. The first step is making each of these visible in the data, which starts with how the test is written.

Structure the Test So NFF Is Visible

An NFF investigation needs three things in the record: the exact measured value (not just pass/fail), the serial number, and a stable set of limits to trend against. A test that only reports pass or fail throws away the information you need.

The example below is a bench acceptance test for a returned unit, written with the TofuPilot framework. Each phase reads a real value and validates it against a limit, so a passing unit still leaves a full measurement trail behind.

name: LRU Bench Acceptance Testversion: 1.0.0description: Functional acceptance test for a returned unit on the repair benchunit:  auto_identify: true  serial_number:    default_value: "LRU000001"  part_number:    default_value: "622-1234-001"plugs:  - name: bench    python: plugs.bench:Benchmain:  - name: Power Supply Check    python: phases.power_check    measurements:      - name: supply_voltage        unit: V        validators:          - operator: ">="            expected_value: 27.5          - operator: "<="            expected_value: 28.5  - name: Signal Integrity    python: phases.signal_check    measurements:      - name: output_delay        unit: us        validators:          - operator: "<="            expected_value: 12.0      - name: signal_snr        unit: dB        validators:          - operator: ">="            expected_value: 40.0

def power_check(measurements, bench):    measurements.supply_voltage = bench.read_supply_voltage()

def signal_check(measurements, bench):    measurements.output_delay = bench.read_output_delay()    measurements.signal_snr = bench.read_snr()

class Bench:    def read_supply_voltage(self) -> float:        return 28.01    def read_output_delay(self) -> float:        return 9.4    def read_snr(self) -> float:        return 44.7

Run it from the procedure directory:

→ Phase: Power Supply Check→ Phase: Signal Integrity✓ Phase Power Supply Check: PASS→   supply_voltage = 28.01 V [PASS]✓ Phase Signal Integrity: PASS→   output_delay = 9.4 us [PASS]→   signal_snr = 44.7 dB [PASS]✓ Run complete: PASS

This unit passes. That is the NFF case. But because the test recorded output_delay = 9.4 us against a 12.0 limit, not just PASS, the next unit that reads 11.8 is visible as a marginal pass long before it fails in service. The value is what lets you trend. The pass/fail alone tells you nothing.

Track Retest Counts

The strongest NFF signal is a unit that gets tested more than once. A single unit cycling through the bench three or four times is either intermittent or being chased in circles. Because each run identifies the unit by serial number, TofuPilot builds a per-unit history automatically. The unit history page shows every run for a serial number, so a repeat visitor stands out without you tracking it by hand.

Sort a part number by retest count and the intermittent units surface at the top. These are the ones worth pulling for a deeper look, and the ones a supplier discussion should be built around.

Trend the Measurement, Not the Verdict

A unit that passes at the edge of its limit is an NFF waiting to happen. To catch it, look at the measured value over time rather than the pass rate.

In TofuPilot, open the measurement for the part number and read the distribution and the drift:

• Distribution. If passing values cluster near a limit instead of centering in the range, the design or the process is running close to the edge. Marginal units are passing today and will fail tomorrow.
• Cpk. A Cpk below 1.0 means the spread does not fit inside the limits reliably. Some fraction of units will always fall out, and some of those are your NFF returns.
• Drift. A slow shift in the mean points to aging, a supplier change, or a bench that has moved. Catching the shift early is the difference between one investigation and a batch of returns.

This is the same statistical basis manufacturing teams use for yield, applied to a repair line. The question shifts from "did this unit pass" to "is this measurement healthy across every unit we see."

Alert on the Signal Automatically

Reviewing charts by hand does not scale. TofuPilot can watch the data and raise an alert when the NFF pattern appears:

• Measurement drift. Fires when a measurement moves off its own baseline, whether a mean shift or a falling Cpk, so a drifting part is flagged before it becomes a wave of returns.
• Retest threshold. Fires when a unit is tested more often than the procedure's normal rate. The threshold self-calibrates per procedure, so you are alerted on the genuinely abnormal units, not the routine ones.

The alerts learn each procedure's normal behavior, so you set them once rather than hand-tuning limits per part.

What Good Looks Like

A repair line with NFF under control has a few visible traits. Retest counts are low and flat, with few units cycling back. Measurement distributions center inside their limits rather than crowding an edge, and Cpk stays above 1.0. When a value does start to drift, an alert catches it while it is still one part, not a batch.

None of this requires new hardware or access to anyone's proprietary software. It comes from recording the measured value instead of the verdict, keeping a per-unit history, and trending what you already capture on the bench.