What makes a good bug report?

Model answer

A good bug report lets a developer understand, reproduce and prioritize the problem without asking follow-up questions.

Include:

A clear, specific title that states the symptom and place, for example "Checkout button disabled after applying a coupon on Safari".
Environment: app version or build, device, OS, browser, account type, and the test data used.
Steps to reproduce: short, numbered and starting from a known state.
Expected result and actual result, kept separate.
Evidence: screenshot or video, logs, console errors, network requests and timestamps.
Frequency: always, intermittent, or only under certain conditions.
Severity and impact: who is affected, whether there is a workaround and whether data is at risk.

Keep one bug per report, stay factual and avoid blame or guesses presented as facts. First search for duplicates, and try to narrow down the cause, for example whether it happens on another browser or only after a specific change.

A reproducible report saves the whole team time and is the quickest way to get the bug fixed.

Key points

Specific title, environment and numbered steps to reproduce
Separate expected result from actual result
Attach evidence: screenshots, logs, network traces
State frequency, severity and impact; one bug per report

Likely follow-ups

How do you report a bug you cannot reproduce reliably?
How do severity and priority differ?

Common mistakes

Writing a vague title like "It does not work"
Combining several problems in one report
Omitting the environment and build version