Bugs stall when nobody can reproduce them Most bugs that sit in a backlog for months are not hard to fix. They are hard to reproduce. A good report removes that problem, and it takes about two extra minutes to write.
A title a developer can triage
Write what breaks and where, not how you feel about it. "Checkout: applying a second coupon doubles the discount" can be triaged instantly. "Coupon bug" cannot.
Numbered steps from a clean start
Begin from a state anyone can reach: a fresh incognito window, a named test account, a specific product. Then number every action, including the ones that feel obvious. If the bug needs a particular account, order or file, say which, and attach it.
Expected and actual, separately
Write what should have happened and what did happen as two separate lines. This is what turns a complaint into a specification, and it is often the point where you discover the behaviour is not actually wrong.
Evidence
Attach a short screen recording, the console output, and the failing network request with its status code and response. A stack trace or a request ID saves more developer time than any amount of description. Include the timestamp so the team can find it in their own logs.
Environment
Browser and version, operating system, device and viewport, the build or commit under test, the environment (staging or production), and the account role. "Safari 18 on iPhone 14, staging, build 4821" prevents an hour of guessing.
Frequency and severity
Say whether it happens every time or one time in five, and how much damage it does. We separate severity, which is about the impact on the user, from priority, which is the team's decision about when to fix it. A cosmetic flaw on the checkout button can still be urgent.
The detail testers forget
Whether it is a regression. If the flow worked in the previous release, say so, and say which version you last saw working. That single line often points a developer straight at the change that caused it.
One bug per report
Three problems in one ticket means two of them get closed without being fixed. Split them, and link them if they share a cause.
Apex Automation Team delivers every finding in this format, with a screen recording, console log, network trace and environment attached, and retests each fix so a closed ticket is verified closed. See software testing and QA.
Quick checklist
- Title says what breaks and where
- Numbered steps starting from a clean state
- Expected and actual written as separate lines
- Screen recording, console log and failing request attached
- Browser, OS, device, build and environment recorded
- Frequency and severity stated
- Say whether it is a regression and which version last worked
- One bug per report
Frequently asked
What do your bug reports include?
Steps to reproduce, a screen recording, console output, the network trace, environment details, severity and a suggested fix where we can see one.
Do you retest fixes?
Yes. Every fix is retested and the ticket is only closed once the behaviour is verified, including a check that nothing nearby broke.