Reproduce It or Kill It: Why Bug Reports Without Steps Deserve the Trash

Imagine you're the developer

Imagine you're the developer. You open a bug report. It says: "The app crashes when I do something." No steps. No environment. No screenshot. You stare at it. You try random clicks. Nothing. You close it as "Not Reproducible" and move on. That's the system working as designed. A report without reproduction steps isn't a bug report — it's a suggestion.

Here's my position: every bug report that lacks clear reproduction steps should be rejected on arrival. No exceptions. You're not being mean. You're being efficient. The fact base backs me up: a complete defect report includes reproduction steps, expected vs. actual behavior, severity and priority, environment details, and visual proof (Atlassian, bug life cycle). If you're missing any of those, you don't have a bug yet — you have a rumor.

The cost of sloppy reports

Why be so hard-nosed? Because vague reports waste everyone's time, and time is money. A 2002 study prepared for NIST found that software flaws cost the U.S. economy $59.5 billion annually, even though about half of software development budgets go to testing (NIST, 2010 combination testing news release). That's a lot of cash down the drain. A big chunk of that waste is developers chasing ghosts — bugs that can't be reproduced, so they never get fixed, and then they blow up in production.

The real kicker? The delayed issue effect — the idea that fixing bugs later costs more — isn't always true. A large study of 171 software projects from 2006–2014 found no evidence that issues resolved later cost consistently more effort (arXiv, Menzies et al. 2016). So if you're sitting on a bug that can't be reproduced, you might not be racking up debt. You're just carrying a dead weight.

Reproduction is the first step to fixing

You can't fix what you can't find. The bug life cycle is straightforward: New, Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, Closed (Atlassian, bug life cycle). Every step depends on reproduction. If a tester says "it's broken," you have no idea where to start. If they give you steps, you can run them, see the failure, and then find the code causing it.

Here's a concrete example. Say a user reports a crash on checkout. A good report says: "Go to /cart, add item, click 'Checkout', select 'Credit Card', press 'Submit'. App crashes. Expected: order confirmation. Actual: white screen." That's gold. A bad report says: "Checkout is broken." Which one will get fixed? The first one, every time.

And don't forget the environment. The same code can behave differently across browsers, OSes, and devices. A report that says "Chrome on Windows 11" is already ahead of one that says "my computer." Add a screenshot or a screen recording, and you're practically handing the fix to the developer.

But won't you reject too many bugs?

I hear the counter-argument: "If you reject everything that's incomplete, you'll miss real issues. Users aren't technical. They just want to help." Fair enough. But think about it: a bug report without steps is like a GPS without an address. You can't get there. You'll spend hours guessing, and you'll probably end up lost.

The fix is simple: don't reject the user, reject the report. Send it back with a polite message: "Thanks for reporting this! Could you tell us exactly what you clicked, what you expected, and what happened instead? Also, what device and browser were you using?" Give them a template. Make it easy. If they fill it out, great. If they don't, you've saved your team from a wild goose chase.

Also, remember that a bug that can't be reproduced might not be a bug at all. It could be a one-time glitch, user error, or a misunderstanding. The system has a state for that: "Non-Reproducible" (Atlassian, bug life cycle). Use it. Log it. Move on.

Make the report worth reading

So what does a killer report look like? It has five parts: steps to reproduce, expected result, actual result, environment, and visual proof. That's it. No fluff. And it should be written so a developer can follow it blindfolded.

Here's a warning: never skip the visual proof. A screenshot or a video can save ten minutes of back-and-forth. And if you're testing accessibility, you should also check against WCAG, the Web Content Accessibility Guidelines, which define success criteria at levels A, AA, and AAA (W3C WAI, WCAG 2 Overview). A screenshot of a color contrast failure is worth a thousand words.

Now, about priority vs. severity. Don't confuse the two. Priority is how urgent it is to fix; severity is how much it breaks things (Atlassian, issue priority vs severity). A bug can be severe but low priority if nobody's hitting it. A minor typo can be high priority if it's on the homepage. Your report should include both, but they're not the same.

Reject, refine, and record

Here's the bottom line: reproduction is the heartbeat of bug tracking. Without it, you're just collecting complaints. So set the standard. Make it clear that reports without steps will be returned. Give users a template. Show them what good looks like. And when you get a report that's missing something, don't just accept it and pass it along — reject it, ask for the details, and only then let it into the workflow.

This isn't about being harsh. It's about being respectful of your team's time. Every minute spent guessing is a minute not spent fixing real bugs. And in a world where software failures cost billions, you can't afford to waste a single minute.

So, my recommendation is simple: if you're a team lead, make "repro steps required" a rule. If you're a tester, write reports you'd want to receive. If you're a developer, refuse to work on anything else. Because a bug you can reproduce is a bug you can kill. And a bug you can't reproduce is just a ghost that will haunt you later.

Remember this: the best bug report is the one that lets the developer say, "Got it, I can see it, I'll fix it."

Sources

• Atlassian - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• Atlassian - https://www.atlassian.com/software/jira/guides/issues/priorities
• NIST (2010) - https://www.nist.gov/news-events/news/2010/11/updated-nist-software-uses-combination-testing-catch-bugs-fast-and-easy
• arXiv (Menzies et al. 2016) - https://arxiv.org/abs/1609.04886
• W3C WAI - https://www.w3.org/WAI/standards-guidelines/wcag/