The fastest way to make a tester invisible is to file bugs developers can't reproduce. After a few "works on my machine" closures, I rebuilt how I write reports.
The Title Is a One-Line Summary
Bad: Login broken
Good: Login fails with 500 when email contains a '+' alias
The title should let a developer guess the subsystem before opening the ticket.
The Body: Six Fixed Fields
Environment: [build, OS, browser, account/role]
Preconditions: [exact state before the steps]
Steps: [numbered, reproducible, no "etc."]
Expected: [what should happen]
Actual: [what happened, with the error text]
Evidence: [screenshot/video/network log]
Steps People Can Actually Follow
The mistake is writing steps that assume context you already have. Every step should be runnable by someone who has never seen the feature:
- Log in as a Standard user (not admin).
- Go to Settings → Profile.
- Enter
taiab+test@gmail.comin Email. - Click Save.
Attach the Network Log, Not Just the Screenshot
A screenshot shows the symptom. The network request/response shows the cause. For that 500 error, the response body revealed the backend was treating + as a space and failing validation — the developer fixed it in minutes because I handed them the payload.
Severity vs Priority
Keep them separate:
| Meaning | |
| Severity | How bad is the impact? (data loss > cosmetic) |
| Priority | How soon must it be fixed? (business call) |
A typo on the landing page can be low severity but high priority before a launch.
Reproduce It Yourself First
Before filing, I reproduce on a clean session. If I can't reproduce it twice, the report says so explicitly — intermittent bugs are real, but pretending they're deterministic just gets them closed.