File a reproducible bug report
Find a bug in any open-source web application through exploratory testing. Write a complete bug report with: a clear title stating the observation, numbered steps to reproduce, expected versus actual behaviour, environment details, severity justification, and any evidence (screenshots, console errors, network traces).
Why this matters
A bug that cannot be reproduced is a bug that will not be fixed. The discipline of writing reproducible bug reports is one of the most high-leverage skills in quality engineering; it directly determines how quickly developers can act on your findings. A great bug report is a gift; a vague one is a time tax on the whole team.
Before you start
- Access to an open-source web application with a running test or demo environment
- Browser developer tools (Chrome or Firefox DevTools)
- A bug tracking system or just a text document to write the report
- 30-60 minutes for an exploratory session
Step-by-step guide
- 1
Run an exploratory session to find a bug
Pick an open-source web application and explore an area that looks complex: a form with many validation rules, a table with sorting and filtering, a multi-step wizard. Use the charter format from the test charters exercise. Look specifically for edge cases around data input, navigation, and concurrent actions.
- 2
Verify reproducibility before writing
Once you find something interesting, reproduce it three times before writing a word. If it only happens once, note the conditions carefully and try to make it happen again. An intermittent bug report that says 'sometimes fails' is almost unusable; 'fails on every third click when X and Y are true' is actionable.
- 3
Write the title as an observation
The title should state what happens, not what you expected: Checkout total updates before delivery cost is removed; not 'Checkout is broken'. A developer reading the title should know which code area to look at without reading the full report.
- 4
Write numbered reproduction steps
Start from an absolute baseline: open a private browser window, navigate to the exact URL, log in with these credentials. Every step should be a distinct action. Test your steps by following them yourself in a fresh browser session. If they do not reproduce the bug, revise them.
- 5
Add environment, severity, and evidence
Record: browser and version, OS, application version or commit hash, whether the bug reproduced in other browsers. Justify the severity: does this block a user from completing their goal? Does it affect data integrity? Attach a screenshot or screen recording; a 30-second recording is worth 10 paragraphs of description.