What is Reproducibility (of a Bug)?

Reproducibility is the degree to which a bug can be made to occur again by following a known set of steps and conditions, a reproducible bug happens reliably when the steps are repeated, while a non-reproducible (intermittent) bug occurs only sometimes or under unknown conditions.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

A bug you can reproduce on demand is a bug you can usually fix: developers can observe it, debug it, fix it, and confirm the fix. That is why clear steps to reproduce are the heart of a good bug report. Reproducibility turns a vague "it broke once" into an actionable, verifiable defect.

Non-reproducible or intermittent bugs are the hard ones. They often stem from timing and concurrency (race conditions), uninitialized or leftover state, environment differences, specific data, network conditions, or memory issues. They are dangerous precisely because they resist the normal fix-and-verify loop, you cannot confirm a fix for a bug you cannot trigger.

Good practice for intermittent bugs is to increase observability and gather evidence: detailed logs, timestamps, screenshots/video, environment and data snapshots, and any pattern in when it occurs (specific users, times, load). Capturing enough context to spot the pattern, and adding logging or monitoring to catch the next occurrence, gradually turns a non-reproducible bug into a reproducible one. Note the reproducibility (always / sometimes / once) in the report so triage can weigh it appropriately.

WHY IT MATTERS

Why interviewers ask about this.

Reproducibility is central to bug reporting and debugging interviews. Explaining why reproducible bugs are fixable, what causes intermittent ones (race conditions, state, environment), and how to chase them with logging and context, demonstrates practical, real-world debugging maturity.

EXAMPLE

Example scenario.

A checkout failure is reported but cannot be reproduced. The tester adds detailed logging and captures the next few occurrences, discovering it only happens when two browser tabs submit nearly simultaneously, a race condition. With that pattern, the bug becomes reliably reproducible and the developer fixes and verifies it.

TIP

Interview tip.

Define reproducibility as how reliably a bug can be triggered again with known steps, and stress that reproducible bugs are far easier to fix and verify. For intermittent bugs, describe your approach: add logging/observability, capture context (timestamps, environment, data), and look for patterns to make it reproducible.

FAQ

Frequently asked questions.

How do you handle a bug you cannot reproduce?

Increase observability and gather evidence: add detailed logging, capture timestamps, screenshots or video, and environment and data snapshots, and look for patterns (specific users, times, load, data). The goal is to capture enough context on the next occurrence to identify the trigger and make the bug reliably reproducible.

What commonly causes non-reproducible bugs?

Timing and concurrency issues (race conditions), uninitialized or leftover state, environment differences, specific data, network conditions, and memory problems. These produce behavior that depends on conditions that are not captured in the obvious steps, so the bug appears only sometimes.