Stuck on 'Cannot Reproduce'? Write a Bug Report a Tester Can Actually Follow

Why Does Every Bug Report Say 'Cannot Reproduce'?

You've seen it a hundred times. A developer reads a bug report, tries the steps, and nothing happens. They mark it 'Non-Reproducible' and move on. The bug sits in limbo, the user gets frustrated, and the defect leaks into production. I've been on both sides of this, and I'm convinced the problem isn't the tester's skill—it's the quality of the reproduction steps. Most bug reports are written like vague diary entries: 'The app crashes when I click around.' That's not a report; it's a riddle. The solution isn't a better bug tracker or more training—it's writing reproduction steps that are so precise, a developer can follow them without thinking. And I'm not talking about adding more screenshots. I'm talking about structure.

What Makes a Reproduction Step 'Good' Anyway?

Let's start with the fundamentals. A complete defect report includes reproduction steps, expected vs. actual behavior, severity and priority, environment details, and visual proof (Atlassian, bug life cycle). That's the checklist. But most people stop at 'steps' and 'expected vs. actual.' They forget the environment, or they write steps that are too high-level. The key is to think like a developer who has never seen your app before. They don't have your context, your data, or your browser extensions. If you say 'click the button,' which button? If you say 'enter a value,' what value? A good reproduction step is a command, not a suggestion. It's a sequence of actions that leads to a specific, observable outcome. And it's reproducible—meaning anyone, anywhere, can follow it and get the same result.

The Anatomy of a Reproduction Step: Be a Scientist, Not a Storyteller

I'm a big fan of the scientific method. You don't just say 'this happened'; you say 'under these conditions, with these inputs, this happened.' That's the core of a good bug report. For example, instead of 'The login form doesn't work,' write: '1. Go to the login page at https://example.com/login. 2. Enter email '[email protected]' and password 'password123'. 3. Click the 'Sign In' button. 4. Expected: You are redirected to the dashboard. 5. Actual: The page reloads, and a red error message appears at the top: 'Invalid credentials.' This tells the developer exactly what you did, what you expected, and what you saw. It's not a story; it's a protocol. And it includes the environment—browser, OS, device—because those matter. A bug that only happens in Safari on macOS might not reproduce in Chrome on Windows. The NVD doesn't test vulnerabilities itself; it relies on vendors and researchers to provide information (NVD, National Vulnerability Database). Similarly, you are the researcher for your bug. You have to provide the data.

Your Environment Is Half the Bug—Don't Skip It

I can't stress this enough: the environment is not optional. It's not a 'nice to have.' It's often the root cause. If your bug only happens on a specific browser version, or a specific operating system, or with a specific configuration, you need to say so. For example, 'I'm using Firefox 120.0 on Windows 11, and the bug appears.' That's a starting point. But go further: what's the screen resolution? Is it a mobile device? What network are you on? The more detail, the better. This isn't just for the developer's convenience—it's for your own sanity. How many times have you seen a bug that 'just won't reproduce' and then later found out it only happens on a VPN or with a particular language setting? The environment is the context. Without it, you're guessing. And guessing is expensive. Consider this: a 2002 study prepared for NIST found that software flaws cost the U.S. economy $59.5 billion annually (NIST, 2010 combination testing news release). A lot of that cost is wasted time trying to reproduce bugs that should have been reproducible in the first place.

How to Write Steps That Actually Work: My Personal Rules

Over the years, I've developed a set of rules for writing reproduction steps. They're not original—they're just what works. Here they are:

• Number every step. No paragraphs. Each step is a single action.
• Be specific. Use exact names, URLs, and values. Don't say 'the blue button'; say 'the 'Submit' button in the top-right corner.'
• Include the expected result at each step. That way, the developer knows if they're on the right track.
• Note the actual result. What did you see instead? Be precise. If it's an error message, quote it verbatim.
• Add the environment. Browser, OS, device, screen resolution, anything that might matter.
• Add visual proof. A screenshot or screen recording is worth a thousand words.

These rules are simple, but they're powerful. They turn a bug report from a complaint into a reproducible experiment. And they save everyone time. The developer can focus on fixing the bug, not on figuring out what you meant. The tester can focus on validating the fix, not on defending their report. And the product gets better, faster.

Let me give you a concrete example. Suppose you're testing a checkout form. A bad report would say: 'The checkout form doesn't work when I try to pay.' That's useless. A good report would say: '1. Go to https://example.com/cart. 2. Click 'Proceed to Checkout.' 3. Fill in the shipping address with the following: Name: John Doe, Address: 123 Main St, City: Anytown, State: CA, ZIP: 12345. 4. Click 'Continue to Payment.' 5. Select 'Credit Card' as the payment method. 6. Enter card number 4111 1111 1111 1111, expiration 12/25, CVC 123. 7. Click 'Place Order.' 8. Expected: Order confirmation page. 9. Actual: The page reloads, and a message appears: 'An error occurred. Please try again.' The developer can follow that exactly. They can also see that the bug might be related to the specific card number, the address format, or a JavaScript error on the page. That's the kind of report that gets bugs fixed.

One more thing: don't be afraid to say 'I don't know.' If you can't reproduce the bug consistently, say so. Mark it 'intermittent' and include any patterns you've noticed. But don't use that as an excuse to be lazy. The more effort you put into the report, the more likely it is to be fixed.

Takeaway

Reproduction steps are the heart of a bug report. If they're vague, the bug is dead on arrival. If they're precise, the bug has a chance. My recommendation: adopt the scientific method. Be specific. Include the environment. Provide visual proof. And remember that a bug report is not a story—it's a protocol. Write it so that anyone, anywhere, can follow it and see the same result. That's how you stop 'cannot reproduce' and start fixing bugs.

Sources

• Atlassian (bug life cycle) - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• NIST (2010 combination testing news release) - https://www.nist.gov/news-events/news/2010/11/updated-nist-software-uses-combination-testing-catch-bugs-fast-and-easy
• NVD (National Vulnerability Database) - https://nvd.nist.gov/general