How to Avoid Common App Testing Mistakes
Most rejected reports come from the same 8 mistakes. Here is every one: what it costs you and exactly how to avoid it.
A rejected report is worse than no report: it costs you time, damages your rating, and in some cases results in penalty points. These are the mistakes that new testers make repeatedly: read this once and avoid all of them.
Not reading the test brief
The brief defines scope, known issues, and what to test. Reporting a bug that's already documented as a known issue, or testing a flow that's explicitly out of scope, wastes your time and results in rejection.
How to avoid it
Read the entire brief before installing the app. Highlight: what to test, what to avoid, known issues, test account credentials.
Reporting expected behaviour as a bug
If the brief says 'payments are disabled in test mode' and you report 'payment button does nothing': that's not a bug. This pattern consistently triggers rating penalties.
How to avoid it
Before filing any report, ask: is this in the brief? Is this normal behaviour for this type of app? When in doubt, include a note: 'This may be expected behaviour: please confirm.'
Vague reproduction steps
'Tapped checkout and it crashed' is not reproducible. If a developer cannot follow your steps and see the same bug, the report is useless and will be rejected.
How to avoid it
Write reproduction steps as if giving instructions to someone who has never used the app. Start from: open app → log in → specific navigation path → specific action → result.
Missing device information
Many bugs are device-specific. Without knowing your device model, OS version, and app version, the developer cannot reproduce or investigate the issue.
How to avoid it
Include in every report: device model (from Settings → About, not from memory), OS version, app version number visible in-app or in Settings.
No screenshots or recordings
A report without evidence is hearsay. A screenshot showing the exact moment of a bug, or a screen recording of the sequence leading to a crash, provides proof that cannot be argued with.
How to avoid it
Screenshot every bug at the moment it occurs. Record your screen for crashes, unexpected behaviour, and multi-step flows. Always attach: even if not explicitly required.
Combining multiple bugs in one report
One report should document exactly one bug. Filing five issues in a single report makes it impossible to track, prioritise, or close individual issues.
How to avoid it
One bug = one report. If you find five issues, file five separate reports with separate titles, steps, and evidence.
Submitting without reproducing
If you saw something once but can't reproduce it, you don't have a confirmed bug. Submitting unverified reports that developers can't reproduce is the fastest way to get your rating penalised.
How to avoid it
Try to reproduce every bug at least twice before filing. If it happens consistently: file it. If it happened once and you can't reproduce: try once more, then file with a note that it was observed once but not consistently reproduced.
Filing a report after the window closes
Test windows are strict. A bug report filed after the deadline does not get paid, even if it's an excellent report.
How to avoid it
Never accept a test you can't complete within the window. Check the deadline immediately upon accepting.
Write reports that get accepted: and get paid
Every accepted report on AppTester.co pays $5–$35. Apply and start building your rating.