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.
No account needed · Scored in under a minute against a senior rubric
What does Reproducibility (of a Bug) mean in practice?
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 do interviewers ask about Reproducibility (of a Bug)?
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.
What does Reproducibility (of a Bug) look like in a real project?
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.
How should you talk about Reproducibility (of a Bug) in an interview?
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.
Go Deeper on Reproducibility (of a Bug)
Know the term. These are the courses that turn the concept into something you can demonstrate.
Common questions about Reproducibility (of a Bug)
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.
Which terms relate to Reproducibility (of a Bug)?
Explore related glossary terms to deepen your understanding.
Related Resources
Dive deeper with these related interview prep pages.
Free QA career tools, no account needed
Instant and private, everything runs in your browser. Try them before you sign up.
QA Resume Checker
Instant 0-100 score on automation keywords, impact, and ATS formatting.
QA Cover Letter Generator
A tailored 3-paragraph QA cover letter from your resume and a job post.
QA Application Tracker
Drag-and-drop kanban to track every QA application from Applied to Offer.
QA Take-Home Test Generator
A realistic take-home assignment with a scenario, tasks, and a rubric.
QA LinkedIn Headline Generator
A recruiter-searchable headline, About section, and skills list.
QA STAR Story Builder
Structure a QA behavioral answer with the STAR method and instant checks.
QA Bug Report Generator
Build a clean, reproducible bug report for Markdown, Jira, or plain text.
Boundary Value Analysis Generator
Generate boundary value and equivalence partitioning test cases from a range.
QA Metrics Calculator
Calculate DRE, defect leakage, defect density, and pass rate with interpretation.
QA Test Plan Generator
Build a structured test plan (scope, approach, criteria, risks) in Markdown.
QA Salary Calculator
Estimate QA, SDET, and automation tester pay by level, market, and skills.
QA Offer Evaluator
See total comp, a counter range, and a ready-to-send negotiation message.
Ready to Ace Your QA Interview?
Practice explaining reproducibility (of a bug) and other key concepts with our AI interviewer.
Join 500+ QA engineers already practicing with AssertHired.
A test passes locally but fails in CI about one run in five. Walk me through what you check first, and why.
Scored on the same four dimensions as the real thing: Technical accuracy · Coverage · Clarity · Best practices.
Rather skip ahead? Create a free account