Why this matters
A bug that nobody can reproduce rarely gets fixed. Your bug report is often the only thing a developer sees of your work, so it is where you show your value. Clear bug reporting appears again and again in testing adverts, and it is the skill a new tester can demonstrate most easily in a portfolio.
The parts of a good bug report
- Title: short and specific. It should say what fails and where. "Basket total does not increase when adding a second item" is good. "Basket broken" is not.
- Steps to reproduce: numbered, exact actions starting from a known state, with the data you used.
- Expected result: what should have happened.
- Actual result: what did happen, including any error message copied exactly.
- Environment: device model, operating system version, browser and version, or app version. Note the network too if it might matter.
- Evidence: a screenshot or a short screen recording. Mark the problem area if you can.
- Severity: how serious the effect is, such as critical (money lost, app crashes), major, minor or cosmetic.
- Frequency: does it happen every time, or only sometimes? If sometimes, say how often in your tries.