Bug Report Writing
3 exercises — write effective bug report titles, step-by-step reproduction instructions, and precise Expected/Actual behaviour sections.
0 / 3 completed
Bug report structure
- Title: [Component] [symptom] on [environment] — specific and searchable
- Steps to Reproduce: numbered, with exact inputs, URLs, and element names
- Expected: what should happen according to design or specification
- Actual: what does happen — include error messages and frequency
- Environment: OS, browser/app version, device, build number
1 / 3
A junior developer writes this bug report title:
"Search is slow on big datasets"
Which rewrite follows best practice for a bug report title: [Component] [symptom] on [context]?
Option B is the model answer — it includes the measurable symptom (12+ seconds), the threshold condition (over 50,000 records), and the context (production, Chrome 124). A good bug report title answers "What happens, under what conditions?" in one line.
Option A is vague: "broken" and "large" are undefined. Option C gives no useful information for triage. Option D uses emotional language ("URGENT") which belongs in the priority field, not the title.
Option A is vague: "broken" and "large" are undefined. Option C gives no useful information for triage. Option D uses emotional language ("URGENT") which belongs in the priority field, not the title.