Bug reports a developer can act on without a call

6 October 2026 · 4 min read

A good bug report is a reproduction, a gap and a consequence. Everything else is decoration.

The test of a bug report is simple: can a developer who was not in the room fix the problem from the report alone, and know when they have fixed it. Most reports fail that test, and the cost is a meeting per bug. Ours follow one shape, whether the bug is a wrong total in a cart or an authorisation hole in an API.

The shape

A title that states the gap, not the symptom. "Removing a coupon after a quantity change keeps the discount on the screen", not "cart bug".
Severity on a scale everyone shares, with the reason in one line: who is affected and what it costs them.
The environment, exactly: build, browser, account type, data. A bug that only appears for guests is a different bug.
Steps that start from a clean state and that we have run twice. Numbered, with the expected and actual result at the end of the list, not scattered through it.
Evidence a developer can trust: a request and response, a log line, a screenshot with the time visible. Redacted, never faked.
The root cause when we know it, marked as a hypothesis when we do not. Developers can smell a guess dressed as a fact.
The fix we would make, and how we will know it worked. That last line becomes the retest.

What we leave out

Opinions about the code, adjectives, and anything a reader would have to ask about. If a report needs a call to be understood, we rewrite the report. The call is for deciding what to fix first, not for explaining what broke.

Why it matters more than it looks

A report is the only part of a testing engagement that outlives it. Six months later, when the same area changes again, someone opens the old report to see what went wrong last time. If it reads like a chat transcript it is useless. If it reads like evidence, it is the start of the regression suite.