Reproducing the bug that happens once
An intermittent bug is not unreproducible. It is a bug whose trigger you have not identified yet, and there is a method for finding it.
"Cannot reproduce" closes more real defects than any other resolution. Sometimes it is correct. Usually it means the person who tried did the same three things the reporter did, saw it work, and stopped.
An intermittent bug still has a cause. It has a trigger you have not found.
Write down what was different
Start with the state, not the steps. Almost every one-time bug is a state bug, and the state is what nobody records.
- How old was the session? A token that expires at sixty minutes produces a bug at minute sixty-one and never at minute two.
- What was open elsewhere? A second tab, an admin panel, the same account on a phone.
- What order did things happen in? Two requests that usually arrive in one order and sometimes do not.
- What data was involved? The account with fourteen thousand rows behaves differently from your test account with three.
Attack the timing directly
Once you have a candidate, stop guessing and force it. Run the flow on a throttled connection. Open the second tab and leave it stale. Click the button twice in the same tick.
// the double submit a real user produces by accident,
// and a scripted test never does
await Promise.all([submit(), submit()]);Half the "once" bugs we chase are a race between two things a user can genuinely do at the same time, and the fastest way to see one is to stop being polite to the interface.
Use what the system already recorded
The reporter's memory is the worst source available, and it is usually the only one anyone asks. Better sources are sitting there:
Server logs around the timestamp. The error tracker's breadcrumb trail. A session recording if you have one. The database row, which often shows the impossible state directly and tells you what the code allowed.
A bug you can see in the data is a bug you no longer need to reproduce in the UI.
Know when to stop
Timebox it. An hour, sometimes two, and then make a decision rather than drifting: add logging and ship it, or accept it and put it on the list.
Adding the logging is not a defeat. It converts a bug nobody can reproduce into one that will report itself the next time it happens, which for a one-in-a-thousand defect is the fastest path there is.
