A good defect report contains enough information for a developer to reproduce and fix the issue: ID, title/summary, description, steps to reproduce, expected vs actual result, severity, priority, environment, and attachments (screenshots/logs/video).
Essential fields: a unique ID; a concise, specific SUMMARY (not 'it's broken'); STEPS TO REPRODUCE (numbered, exact); EXPECTED vs ACTUAL results (the crux); SEVERITY and PRIORITY; ENVIRONMENT (browser/OS/build/version); and ATTACHMENTS (screenshot, console/network logs, video). Optional: preconditions, test data, reproducibility (always/intermittent), and a link to the requirement/test case. A vague or non-reproducible report wastes developer time and gets bounced back. Writing clear, reproducible defect reports is a core manual-testing skill interviewers directly assess.
Bug summary 'Checkout button unresponsive on Safari 17 after applying coupon' with numbered repro steps, expected vs actual, build number, and a screen recording — a developer can reproduce it immediately.
A developer keeps returning your bugs as 'cannot reproduce'. What's likely missing and how do you write a better report?