Application to Reclassify Test Retry Superstition
An engineer reruns failing tests before reading them because a passing retry costs nothing and feels like information.
I. The Test Has Failed
The test failed. The output is available. Reading it takes ninety seconds.
Nobody reads it immediately.
The first response to a failing test is to run it again. This is not random. The logic is sound: tests can fail for transient reasons. Network calls. Timing dependencies. Race conditions. A retry that passes confirms a transient failure and closes the incident with no further action required.
The retry is fast. The reading is slow. The retry might produce the good outcome. Reading will definitely produce work.
Under the governing rule: any test retry superstition that restores service once may be reused until someone proves why it worked.
II. The Retry Statistics
In practice, a high proportion of test failures that would pass on retry are already known as flaky. The rest are genuine failures, and genuine failures will not pass on retry.
The retry confirms nothing in the second case and confirms "flakiness" in the first, which is itself a problem worth investigating.
Neither outcome eliminates the need to read the failure. The retry delays the reading by approximately twelve seconds.
These twelve seconds are reliably spent.
III. The Superstition Cycle
The retry sometimes passes. This is remembered. The retry is therefore always attempted.
The retry that passes is remembered as efficient. The retry that fails is followed by the reading that was always required.
The retry never costs more than twelve seconds. Over months, it costs more. Over teams, more still. The most useful thing the retry does is feel like a reasonable first step before the necessary second step.
The behavior persists because it is not wrong. It is simply never right in the way the person performing it believes.
IV. The Failure Report
The failure output contains the answer.
Nobody looked at it first.