Bug reports that get fixed
Finding a bug is half the job. Reporting it so a developer can act immediately is the other half — and it's the skill that gets juniors kept.
5 steps · 5 minThe anatomy of a good report
Every report a developer loves has four things: steps to reproduce, what you expected, what actually happened, and the environment (browser, device, version). Miss any one and the bug stalls.
Which title will get a developer's attention fastest?
Severity vs priority
Severity is how bad the bug is technically. Priority is how soon it should be fixed given the business. A tiny crash on a rarely used admin page can be high severity but low priority — they're not the same axis.
Reporting both helps the team decide without re-investigating your bug themselves.
Which of these is a report a developer can act on immediately?
Reproducibility is everything
A bug a developer can reproduce is a bug that gets fixed. If it only happens sometimes, say so and include exactly what you were doing — intermittent bugs still deserve precise notes, not a shrug.
You've now got the full beginner foundation: think like a tester, know the role, read the business, test by hand, and report clearly.
Lesson complete.
You just practiced the real work of QA — predicting failure, probing the edges, and reporting clearly. That instinct is the foundation everything else builds on.