How to Write a Bug Report Developers Actually Act On

I can usually tell how a bug report is going to be handled just from reading the title. "Checkout is broken" sits in a backlog. "Checkout fails with a 500 when the discount code field is left empty and the cart has more than one item" gets picked up the same day, because the second one is already half a fix.

Steps to reproduce is the whole report

Everything else is decoration if this part is missing. Exact steps, exact data you used, the environment you were in. Not "add items to cart and check out," but the specific sequence, with the specific values, that produced the bug. If a developer has to guess at what you actually did, they're not fixing your bug, they're trying to find their own version of it first.

Expected versus actual, stated plainly

State what you thought should happen and what happened instead, as two separate sentences. "This is broken" tells a developer nothing they didn't already know from your title. "Expected the confirmation page to show the updated total; actual total still shows the pre-discount price" tells them exactly where to start looking.

Severity and priority aren't the same axis

Severity is how bad the bug is on its own terms: does it crash, lose data, block a core flow, or just look slightly off. Priority is how urgently it needs fixing given everything else on the team's plate right now, and that's a product call, not a testing call. Report severity honestly even when you suspect priority will be low. Conflating the two is how a genuinely severe bug in a rarely used feature gets read as "minor" just because it's not this week's priority, and then nobody revisits it when it becomes one.

Attach the evidence, not because it's required

A screenshot, a short screen recording, a console error, the request and response body if it's relevant. Not because a template says you have to, but because it saves the two follow-up messages a developer would otherwise have to send you before they can start. I'd rather spend thirty extra seconds attaching a network log than have a bug sit for two days waiting on a Slack reply I could have skipped entirely.

The one I still think about

I filed a bug on a Friday afternoon with a screenshot and no repro steps, because the screenshot felt obvious enough on its own. It sat for two sprints. Nobody could reproduce it from a screenshot alone, and by the time someone asked me for the steps, I'd genuinely forgotten the exact sequence myself. I don't skip the steps anymore, even when I'm sure the bug speaks for itself. It never does, for the person who wasn't there when it happened.

Good bug reports and good exploratory testing go together: the finding is only worth as much as the report that lets someone else act on it. If your team's manual testing process could use a second pass on this, that's part of what we look at in manual testing engagements.