How to Write Bug Reports That Developers Can Actually Use
The difference between a good tester and a great one is the quality of their bug reports. Here is exactly how to write reports that get fixed, earn higher ratings, and lead to more tests.
A vague bug report is worse than no bug report. If a developer cannot reproduce a bug, they cannot fix it. And if a tester repeatedly submits vague reports, they stop getting assigned tests. Here is the format that works every time.
The anatomy of a great bug report
Title
Bad
App crashes
Good
App crashes when tapping 'Pay Now' button on checkout screen after adding a promo code
The title should be a one-sentence summary that describes exactly what breaks and where. A developer reading only the title should know which feature to look at.
Environment
Bad
My phone
Good
Samsung Galaxy A54, Android 14, App version 2.3.1, WiFi connection
Bugs are often device or OS specific. Without this information, the developer cannot reproduce the issue on their test setup.
Steps to reproduce
Bad
Go to checkout and tap pay
Good
1. Open app and log in. 2. Tap any product. 3. Tap 'Add to Cart'. 4. Tap cart icon. 5. Enter promo code 'SAVE10'. 6. Tap 'Pay Now'.
Steps must be specific enough that someone who has never used the app can follow them and see the same bug.
Expected result
Bad
(missing)
Good
Payment screen should open, prompting for card details.
Without knowing what should happen, the developer cannot verify the fix.
Actual result
Bad
It crashed
Good
App closes immediately with no error message. On re-opening, the cart is empty.
Describing exactly what happened (including secondary effects) helps diagnose the root cause.
Reproducibility
Bad
(missing)
Good
Happens every time with any promo code. Does not happen without a promo code.
Knowing whether a bug is consistent or intermittent dramatically affects how developers prioritise and debug it.
Severity
Bad
(missing)
Good
Critical: prevents payment completion
Severity helps developers prioritise. Critical = core flow broken. High = major feature broken. Medium = degraded experience. Low = minor visual issue.
Attachments
Bad
(none)
Good
Screenshot of the crash moment + short screen recording of the full flow
Visual evidence eliminates ambiguity. A 30-second recording of a crash is worth ten paragraphs of description.
Common mistakes that get reports rejected
Combining multiple bugs in one report
Fix: One report per bug. If you find 5 issues, file 5 reports.
Reporting expected behaviour as a bug
Fix: Read the test brief carefully. If the brief says 'the payment will show an error in test mode', that is not a bug.
Missing reproduction steps
Fix: If you cannot reproduce it yourself, do not file it. Test once more to confirm before submitting.
No screenshots or recordings
Fix: Always attach a screenshot minimum. For crashes, always record the screen.
Vague severity ratings
Fix: Critical = cannot proceed. High = major feature broken. Medium = degraded. Low = cosmetic.
Wrong device info
Fix: Copy your exact device model from Settings → About Phone, not from memory.
What to do when you find no bugs
A clean test result is a valid result. Write a summary report describing every flow you tested, what worked well, what felt slightly off even if not technically broken (these UX notes are valuable), and any suggestions for improvement. Developers value knowing their app works as much as knowing what breaks.
Never fabricate bugs to appear more thorough. Reported bugs that cannot be reproduced damage your rating significantly: more so than a clean report.
Ready to start writing reports that get paid?
Apply as a tester on AppTester.co. We pay $5–$35 per test and provide structured briefs that make great reporting straightforward.