Q3 of 38 · Manual & exploratory
What information should every bug report include?
Manual & exploratoryJuniorbug-reportingcommunicationprocess
Short answer
Short answer: Title, environment, steps to reproduce, expected vs actual behaviour, severity, and supporting evidence (logs, screenshots, network traces). The goal is to let a developer reproduce it without asking you anything.
Detail
A great bug report passes one test: a developer should be able to reproduce the bug from your report alone, with zero follow-up questions. Working backward from that test gives the standard fields:
- Title — short, specific, scannable in a triage queue ("Login button no-ops after second click on Safari", not "Login broken").
- Environment — browser/OS/device, app version, build number, user role, feature flags.
- Preconditions — required account state, data, or setup steps.
- Steps to reproduce — numbered, deterministic, and minimal. If a step is irrelevant to the bug, leave it out.
- Expected vs actual — what the spec or sane defaults imply versus what you observed.
- Severity / impact — how many users, how often, what's the workaround.
- Evidence — screenshots or video for UI bugs, network HAR for API issues, logs/stack traces for crashes.
Skipping the boring fields is the most common failure. "It doesn't work on staging" is not a bug report; it's a help request. Treat the report as a contract: you've done enough investigation that the developer's job is to fix, not to investigate again.
// EXAMPLE
bug-report.md
### Title
Login button no-ops after second click on Safari 17
### Environment
- App version: 4.12.0 (build 4127)
- Browser: Safari 17.3
- OS: macOS Sonoma 14.4
- User role: standard
### Steps to reproduce
1. Go to /login
2. Enter valid credentials
3. Click "Sign in" once — request fires correctly
4. Click "Sign in" a second time within 2 seconds
### Expected
Second click is debounced or the button is disabled while in flight.
### Actual
Second click is silently swallowed. No network request, no error,
no UI feedback. User thinks the page is frozen.
### Evidence
- Screen recording: bug-1234.mov
- Network HAR: bug-1234.har
- Console: no errors logged
### Severity
S2 — affects ~3% of Safari users based on session replays.// WHAT INTERVIEWERS LOOK FOR
Empathy for the engineer reading the report and a structured approach. Strong candidates mention severity/impact and evidence, not just steps.
// COMMON PITFALL
Listing fields generically without explaining the goal (reproducibility). Junior candidates often forget environment details and severity.