5 exercises on writing clear, reproducible bug reports — numbered steps, minimal examples, environment details, and Expected vs Actual.
Key patterns
Number the steps; start each with a verb (Open, Click).
End with Observe: the actual, visible result.
Provide a minimal reproducible example — strip everything non-essential.
Pin the environment: OS, browser/runtime version, app build, tier.
Contrast Expected vs Actual as two concrete statements.
0 / 5 completed
1 / 5
You are filing a bug. Which set of reproduction steps is the clearest and most actionable for another engineer?
Good repro steps are numbered, deterministic, and end with an observable result.
Option C names the precondition (logged in as a standard user), the exact actions with a real URL and button label, the precise timing that triggers the race (twice within ~1 second), and a concrete outcome.
Lead each step with a verb: Log in, Add, Open, Click.
Quote UI labels exactly (Place order) so the reader can find them.
End with Observe: or Result: describing what actually happens.
The other options use vague hedges — sometimes, breaks, click around — that force the reader to guess. "ASAP" is a priority signal, not a step.
2 / 5
Your report has a steps list. Which addition makes it a minimal reproducible example?
"Minimal" means you have removed everything that is not required to trigger the bug. A minimal reproducible example (often shortened to MRE or repro) lets a maintainer confirm the issue in seconds.
Strip unrelated setup, extra dependencies, and noise.
Provide self-contained sample input or a short script.
State the smallest version/config where it still occurs.
Pasting a 400-line file (Option C) or padding with "just in case" steps (Option D) does the opposite — it buries the signal. "Works on my machine" (Option A) gives the reader nothing to run. The phrase to learn: "Here is a minimal repro."
3 / 5
Which line states the environment most usefully in a bug report?
Environment details must be specific and versioned so the bug can be reproduced — and so the team knows whether it is already fixed.
Option C pins the OS, the exact browser build, the application build number, and which backend (staging) was hit. That is enough to rule out "already fixed in v3.8.2" or "only on staging data".
"the latest version" rots instantly — name the actual build (v3.8.1).
Include OS, browser/runtime version, and app/build number.
Note the environment tier: local, staging, or production.
Vague phrases like "recent browser" or "my computer" force a back-and-forth that wastes a triage cycle.
4 / 5
How should you present Expected vs Actual behaviour for clarity?
State Expected and Actual as two parallel, concrete statements. The gap between them is the bug, so each side must be observable and specific.
Option B contrasts a precise success state (a green Saved toast, the row updating) with a precise failure (a ~30s spinner, a 500, no change). A reader instantly sees the delta.
Never write "it works / it doesn't work" — that conveys nothing.
Quote real messages and status codes in Actual.
Do not assume the expected behaviour is "obvious" (Option D) — make it explicit.
Useful framing verbs: Expected … but instead …, should … whereas it currently ….
5 / 5
A teammate's repro says: "Sometimes the export fails." Which rewrite best improves it?
Replace "sometimes" with frequency, conditions, and a count. Intermittent bugs are hard to fix precisely because they are under-specified — quantifying them is the single most valuable rewrite you can make.
Option C names the trigger condition (more than 10,000 rows), the frequency (~1 in 5), the failure point (stops at ~60%), and a reproduction count (4/20) on a named build. That turns a shrug into a lead.
Quantify: 1 in 5, ~20% of attempts, 4/20 runs.
Pin the condition that makes it more likely (large datasets, specific input).
Note the reproduction rate so others know what counts as "still broken".
The rejected options stay vague ("quite often", "buggy", "not always") and add emotion instead of data.