Handling 'Cannot Reproduce' Bugs (Without Losing Your Mind)

"Cannot reproduce" is the bug ticket status that both QA and developers dislike. QA sees a real issue. Developer can't replicate it. The ticket goes to a limbo state. The bug may or may not ship.

Sometimes "cannot reproduce" is legitimate — the bug was environment-specific and truly can't be replicated. Often, it's a solvable information problem.

Why "Cannot Reproduce" Happens

Different environment. QA tested on a Samsung Galaxy A52 running Android 12. Developer is reproducing on a Pixel 7 running Android 14. The bug only affects certain OEM builds.

Insufficient reproduction steps. The steps are too vague. "Go to the checkout screen and tap Submit" — but which state? Logged in or guest? With or without a saved payment method? Cart with 1 item or 10?

Missing preconditions. The bug requires specific app state that the developer doesn't know about and didn't set up.

Timing/race condition. The bug requires a specific timing — tap quickly, slow network, app in background for exactly X minutes. Without knowing this, reproduction is random.

Already fixed. The developer fixed an adjacent bug that happened to resolve this one. Nobody knows this. The "cannot reproduce" is accidentally a "fixed."

Prevention: Better Bug Reports

The single best intervention: more context in the original report.

Required in every bug report:

Device: Samsung Galaxy A52
OS: Android 12 (One UI 4.1)
App version: 2.3.1 (build 231)
Account state: Logged in, free tier, 3 items in cart, saved payment method
Network: Wi-Fi
Reproducibility: 3/3 attempts

Exact steps to reproduce:
1. [specific starting state]
2. [exact action]
3. [exact action]
4. Observe: [exact failure]

Screenshot/recording: [attached]
Logs: [attached]

A bug report with all of this is reproduced on the first try most of the time. The developer has everything they need to set up the exact state that triggers the bug.

When You Get "Cannot Reproduce"

Don't accept it as a final answer. Work through this checklist:

Step 1: Verify the reproduction steps are complete. Can you reproduce it yourself right now? Walk through the exact steps and confirm it still happens. If you can't reproduce it either, it may have been fixed or was environment-specific.

Step 2: Document the environment precisely. Provide the exact device model, exact OS build (not just version number — "Android 12" vs "Android 12 (build SP1A.210812.016)"), exact app build number. OEM build details matter.

Step 3: Provide additional context about timing or state. What had you been doing before you encountered this? Was the app freshly opened or had it been running for hours? Was the device recently charged or on low battery?

Step 4: Provide a screen recording. Video eliminates all ambiguity about steps. If the developer says "I followed the steps exactly," a recording proves what "exactly" means.

Step 5: Request a pairing session. For persistent "cannot reproduce" bugs, 20 minutes of screen share between QA and developer — QA reproducing while developer watches — is faster than ten comment exchanges. Developer immediately sees the exact conditions.

The "Intermittent" Classification

Some bugs are genuinely intermittent — they reproduce at 1-in-20 rate or depend on specific server states or race conditions that are hard to create deliberately.

For these:

Document the reproduction rate explicitly. "1 in 10 attempts" is actionable. "Random" is not.

Capture as much context as possible when it occurs. The moment you see it, capture logs immediately before the state changes.

Look for patterns. Time of day, network condition, device battery level, background apps. Intermittent bugs often have triggers that look random but aren't.

[!TIP] For intermittent bugs on Android, keep a running logcat capture active during testing sessions. When the bug appears, the full log history before the failure is available. Without this, you're trying to reproduce from memory.

Preventing "Cannot Reproduce" as a Bug Killer

Some teams use "cannot reproduce" to close bugs without fixing them. This is a dysfunction that needs explicit policy attention.

Policy: "Cannot reproduce" requires:

• Documentation of the reproduction attempt (what was tried, what environment)
• 48-hour window for QA to provide additional information
• If still not reproduced after additional info: classification as "environment-specific — monitor for recurrence" rather than "closed"

Bugs that are "closed: cannot reproduce" and then reappear in production are process failures. Tracking the recurrence rate of CNR bugs is a useful quality metric.