A tester's most visible product is not the tests. It is the bug report. A defect that nobody can understand or reproduce often does not get fixed, no matter how serious it is. A clear report gets fixed faster and earns the tester the trust of the whole team.
This step in our software testing learning path covers what goes into a good bug report and the habits that make one. It builds on Your First Test Cases.
Who reads a bug report
Before writing, picture the readers:
- A developer who needs to find the defect in the code. They need exact steps and conditions.
- A manager or product owner who decides what gets fixed first. They need to know the impact on users in one line.
- Another tester, sometimes months later, who needs to check the fix. They need to repeat exactly what you did.
A good report serves all three without making any of them dig.
The parts of a good bug report
1. A summary that stands on its own. One sentence that says what fails and what it does to the user. Compare:
- Weak: "Checkout broken."
- Strong: "Checkout charges shipping twice when a discount code is applied."
The strong version tells a manager the impact and tells a developer where to start looking, before anyone opens the report.
2. Steps to reproduce. Numbered, specific, starting from a known state:
- Sign in as a customer with an empty cart.
- Add any one item priced under $50.
- Go to checkout and choose standard shipping ($5.99).
- Enter discount code
SAVE10and click Apply.
3. Expected result. "Order total is item price minus 10%, plus $5.99 shipping, charged once."
4. Actual result. "Shipping of $5.99 appears twice in the order summary; total is $5.99 too high."
5. Environment. Where it happened: device, operating system, browser and version, app version, and which test environment. Many defects only appear in one setting.
6. How often. Every time, or intermittently? If intermittent, roughly how often: "3 of 10 attempts."
7. Evidence. A screenshot, a short screen recording, or an error message copied as text. Evidence ends arguments about what happened.
8. Severity. Your assessment of the impact. (The team usually sets priority. See Errors, Defects, and Failures for the difference.)
Before you submit: the professional habits
Rex Black's published bug reporting process, used by professional test teams, includes steps that turn a rough observation into a report developers trust. Several of them apply even to your very first report:
- Reproduce. Try it again before reporting. If you cannot make it happen a second time, say so and record exactly what you did.
- Isolate. Change one thing at a time to find what matters. Does it happen with every discount code or just one? On every browser? This narrows the developer's search enormously.
- Generalize. Look for the bigger version of the problem. If shipping doubles with discount codes, does it also double with gift cards? A more general bug is often more serious.
- Compare. Did it work in the previous version? A problem that just appeared points straight at recent changes.
- Condense. Remove anything that does not help someone understand or reproduce the problem.
- Disambiguate. Replace vague words. "Sometimes", "weird", and "doesn't work" are not facts. "3 of 10 attempts" and "shows a blank page" are.
- Neutralize. Describe the behavior, not the people. "The total is wrong" is a fact. "Whoever wrote this was careless" helps nobody and makes the next conversation harder.
The full ten-step version is in our free QA Library: the bug reporting process checklist.
One bug per report
If you find two problems, write two reports. Combining them causes trouble: one gets fixed, the other gets forgotten, and the report sits half-closed. Separate reports can be fixed, tested, and closed independently.
A complete example
Summary: Checkout charges shipping twice when a discount code is applied.
Steps: (1) Sign in as a customer with an empty cart. (2) Add one item under $50. (3) At checkout choose standard shipping ($5.99). (4) Apply code
SAVE10.Expected: Item price minus 10%, plus $5.99 shipping once.
Actual: Shipping listed twice; total $5.99 too high.
Environment: Chrome on Windows 11; also reproduced in Safari on iOS. Test environment build 4.2.1.
Frequency: 10 of 10 attempts.
Isolation: Happens with every discount code tried (3 codes). Does not happen without a code. Does not happen with gift cards. Did not happen in build 4.2.0.
Evidence: Screenshot of order summary attached.
Severity: High. Customers are overcharged.
A developer reading that can start fixing immediately, and the line about build 4.2.0 tells them which change to examine first.
Try it yourself
Take any test you ran in the earlier steps, or any glitch you have noticed in a real app, and write a full bug report using the format above. Then reread it as if you were a developer who has never seen the app. Could you reproduce it from the report alone? If not, revise it.
The last step in this level looks at where these skills lead: the roles in software quality and how people start a career in it.