Get Started
bug-reportreproduceqadebugging

How to Reproduce a Bug: A Step-by-Step Guide

BugReel Team

“Works on my machine.” The developer can’t reproduce the issue, so it gets marked “cannot reproduce” and closed. The tester knows the bug is real — they saw it — but without a reproducible case, it’s their word against the codebase.

Reproducing bugs is a skill. It’s about systematically eliminating variables until you isolate the exact conditions that trigger the defect. Here’s how to do it.

Why Reproduction Matters

A bug that can’t be reproduced can’t be fixed with confidence. Even if a developer guesses at the cause and applies a patch, they have no way to verify the fix. Reproduction also reveals scope — does it happen with all user roles or just admins? All browsers or just Firefox? These boundaries point directly to the root cause.

Step 1: Match the Environment

The most common reason developers can’t reproduce a bug is that they’re testing in a different environment. Match every variable you can.

  • Browser and version. Chrome 122 and Chrome 124 can behave differently.
  • Operating system. macOS, Windows, and Linux render pages differently.
  • Screen size. Many layout bugs only appear at specific viewport widths.
  • User role. An admin account might bypass the code path that triggers the bug.
  • Data state. The bug might require a specific configuration — 1,000+ records, an expired subscription, or an empty profile.
  • Environment tier. Production, staging, and dev have different data and configs.

If the reporter didn’t include environment details, ask before spending time testing.

Step 2: Follow the Exact Steps

Follow the reported steps exactly as written, in the exact order, at the exact pace. Bugs caused by race conditions can be sensitive to interaction speed — clicking too fast or too slow can change the outcome.

If the steps are vague, work with the reporter to get precise instructions. “Change the display name to a string containing an emoji, then click Save” is actionable. “Change something in settings” is not.

Step 3: Isolate the Trigger

If you can reproduce the bug, the next step is finding the minimal set of conditions that triggers it. Start removing variables one at a time.

  • Without the emoji in the display name? (Input data.)
  • In an incognito window? (Browser extensions and cached state.)
  • With a freshly created account? (Data-dependent conditions.)
  • If you slow down between steps? (Race conditions.)
  • On a different network? (API timeouts, VPN, CDN caching.)

When you find the one variable whose presence or absence determines whether the bug appears, you’ve found the trigger.

Step 4: Check State and Network

Many bugs depend on hidden state that isn’t visible in the UI. Open your browser’s developer tools and watch for clues.

Console tab. Look for JavaScript errors or failed assertions. Silent errors often explain why a button stops responding or a form submits incorrectly.

Network tab. Watch for failed API requests (4xx or 5xx) or unexpected response data. A frontend bug might actually be a backend returning malformed JSON.

Application tab. Check localStorage, sessionStorage, and cookies. Stale tokens or corrupted state are common culprits for bugs that “only happen to some users.”

Tools like BugReel capture console logs and network requests alongside screen recordings automatically, making it easier to correlate user actions with behind-the-scenes behavior.

Step 5: Test Boundaries

Once you can reproduce the bug, explore its edges.

  • Does it happen with 1 record? 100? 1,000? (Threshold-dependent issues.)
  • Does it happen for all user roles or just one? (Permission-related code paths.)
  • Does it happen in all browsers or just one? (Browser-specific differences.)
  • Does it happen on the current version only, or also the previous release? (Regression timing.)

Document what you find. “Reproduces in Chrome and Edge. Does NOT reproduce in Firefox or Safari” is a diagnostic gold mine.

When You Truly Cannot Reproduce

Sometimes, despite your best efforts, the bug won’t appear again. This doesn’t mean it’s not real. Intermittent bugs — race conditions, memory leaks, timing-dependent failures — are some of the most serious defects.

File the report with everything you have. Note the frequency, any patterns, and the system state when it occurred. Mark it as “intermittent” rather than “cannot reproduce” — the distinction matters, because “cannot reproduce” implies the bug might not exist, while “intermittent” tells the team it’s real but elusive.

Our bug report generator includes fields designed for intermittent bugs, helping capture the factors developers need to investigate.

Reproduction Is Diagnosis

By the time you’ve matched the environment, followed the steps, isolated the trigger, and tested the boundaries, you’ve often gathered enough information to point the developer directly at the root cause. Systematic reproduction doesn’t just confirm the bug exists — it explains why.