How do you write a clear, actionable bug report that a developer won't bounce back?

A "bouncing" bug report is one a developer can't act on without coming back to ask: "what browser?", "is this still happening?", "what user?", "do you have a video?". Each round-trip is a day lost and erodes trust between QA and engineering.

The principles:

Lead with the punchline. Title and the first paragraph should let a developer decide priority in 10 seconds. "Login fails silently for users with non-ASCII passwords on Safari" is informative; "Login bug" is not.

Anticipate questions. Before submitting, ask: which environment, which user, when, how often, what changed recently, what error in the console. If you can't answer those, find the answer before submitting — the developer will ask anyway.

Provide a minimum reproduction. Strip the steps to the smallest reliable repro. If the bug only happens with specific data, include the data.

Include evidence proportional to the bug. UI bug → video or annotated screenshot. API bug → request/response with redacted secrets. Crash → stack trace and console. Performance → timing data.

Be precise about expected vs actual. "It doesn't work" is useless. "Expected: discount applies and total updates to £45. Actual: discount badge appears but total still shows £50, and a console error 'cart.recalculate is not a function' is logged." That report is half-fixed already.

Set severity and impact: "S2, affects all users on Safari, ~15% of traffic" is more useful than "S2".

A bug report is a contract: you've done enough investigation that the developer's job is to fix, not to investigate again. Senior testers are known on engineering teams precisely because their reports never bounce.