What a bad report costs
A report that says “cart doesn’t work” starts a series of questions: where, on which account, in which version. The developer loses time, the tester returns to the topic days later and the bug waits. I’ve reported more than 450 defects across manual and automated testing, and what saved the most time wasn’t fancy tooling but well-written reports.
A good report meets one condition: someone who hasn’t seen the bug can reproduce it.
A title that says something
The title should describe the symptom and the place. The team reads it in a list, often without opening the report.
- Weak:
Cart error - Good:
Cart: discount code disappears after changing product quantity
What the report must contain
Title: Cart: discount code disappears after changing product quantity
Environment: staging, version 2.14.0, Chrome 130, Windows 11
Account: test user with the customer role
Steps:
1. Add a product to the cart.
2. Enter a discount code and confirm.
3. Change the quantity from 1 to 2.
Expected result: the discount stays applied.
Actual result: the discount disappears and the price returns to full.
Reproducibility: 5 out of 5 attempts.
Attachments: recording, console log.Remember three things:
- Steps from the start. Don’t assume the reader knows where you began.
- Expected and actual results kept apart. Without them nobody knows whether it’s a bug or a misunderstanding of the requirements.
- Reproducibility. “Sometimes” is useful too, if you say how often.
Evidence
A recording or screenshot shortens the conversation, and a log often points to the cause. For mobile apps, Logcat helps on Android, and on the backend, the service log from the same moment. For API bugs, attach the request and the response.
Remove real personal data, passwords and tokens from attachments. More people usually see the ticket system than production.
Priority versus severity
These are two different things that are easy to mix up.
- Severity says how serious the technical impact is.
- Priority says how quickly it needs fixing from a business point of view.
A typo in the company name on the home page has low severity and high priority. A failure in a rarely used report can be the opposite. The tester suggests severity, and priority is best agreed together, for example at triage.
One defect, one report
Two problems in one report mean one gets fixed and the other forgotten. Before reporting, also check whether someone has already described the same thing. If so, add new information to the existing report.
Closing the loop
The work doesn’t end with the report. After the fix, check it on the same scenario and around it, because a change in one place likes to break its neighbours. If the same type of bug keeps coming back, add it to regression.
Summary
A good report is a specific title, repeatable steps, two results and evidence. A team can adopt this template in a day, and the gain shows with every next bug. If you want to tidy up reporting and triage, get in touch.
The “Testing from scratch” series
This guide is also the fourth part of a series for people starting out in testing:
- What does a software tester do, and how to get started
- Testing theory in a nutshell
- How to write a test case
- How to report defects (this guide)
- API testing basics
- First steps in test automation