Bug Report Writing Exercise
Practice writing clear, complete bug reports.
Practice writing a clear, reproducible bug report. Fill in each field — a good report needs all of them. The formatted Markdown appears below, ready to copy into your tracker.
About Bug Report Writing Exercise
The Bug Report Writing Exercise gives you a structured template — summary, steps to reproduce, expected vs. actual behavior, environment — and turns your input into a clean Markdown bug report ready to paste into Jira, GitHub or Linear. Writing reports developers act on quickly is a core QA skill, and structure is most of the battle.
Use it as a practice drill or as a day-to-day formatter: fill the fields, copy the Markdown, done. The format nudges you toward the details that prevent "cannot reproduce" round-trips.
How to use
- Fill in each field: a specific one-line summary, numbered reproduction steps, expected and actual behavior, and environment details.
- Watch the "Formatted bug report (Markdown)" panel assemble your report as you type.
- Copy the Markdown into your issue tracker.
Frequently asked questions
What makes a bug summary good?
Specific, searchable and outcome-focused: "Checkout button unresponsive on iOS Safari after applying coupon" beats "Checkout broken". A developer should grasp scope and severity from the summary alone.
How detailed should reproduction steps be?
Detailed enough that someone unfamiliar with the feature reproduces the bug on the first try: numbered actions from a known starting state, with exact data values. Every hidden assumption is a future "works on my machine".
Why state expected behavior explicitly — isn't it obvious?
What is obvious to you encodes your reading of the requirements. Stating it lets a developer disagree productively ("that is actually by design") and turns arguments about behavior into checks against the spec.