Back to blog
QA & TestingPublished July 21, 20266 min read

The Mobile App QA Checklist Professional Testers Actually Use

Beyond tapping through screens: the systematic checklist real testers run before signing off on a mobile app release.

Key takeaways

  • Structured testing works through a checklist across functionality, UI/UX, performance, compatibility, and security — not ad-hoc tapping around.
  • Device and OS-version fragmentation, especially on Android, is the single biggest source of bugs that never show up on a developer's own phone.
  • Network-condition testing — offline, slow connections, interrupted requests — catches a large share of the crashes that would otherwise only surface in production.
  • A test pass isn't complete until edge cases — empty states, denied permissions, interrupted flows — have been exercised, not just the happy path.

Functional testing

  • Every core user flow, start to finish, not just the main happy path.
  • Form validation: empty fields, max-length input, special characters, pasted text.
  • Both branches of every permission prompt — granted and denied — handled gracefully.

UI/UX & accessibility

  • Layout across multiple screen sizes and both orientations.
  • Dark mode and light mode, including any custom-themed screens.
  • Text scaling at larger accessibility font sizes without broken layouts.
  • Tap target sizes and basic screen-reader compatibility.

Performance & stability

  • Cold start time, and behavior when the app is backgrounded and resumed.
  • Memory usage over a longer session, not just the first few minutes.
  • Battery drain during typical use, not only during heavy stress tests.
  • Crash-free session rate across the test group, tracked build over build.

Compatibility

A matrix spanning the oldest OS version still officially supported through the latest release, and device tiers from low-end to flagship. This matters far more on Android, where manufacturer UI skins and hardware variety create bugs that simply don't exist on a single reference device.

Network & data conditions

  • Full offline mode, and the transition back to online.
  • Slow or flaky connections, not just a fast Wi-Fi test network.
  • Interrupted uploads or downloads, and whether retry logic actually recovers.
  • Server error responses (4xx/5xx) surfaced to the user instead of a silent failure.

Security basics testers check

  • No sensitive data logged in plaintext or left in local storage unencrypted.
  • Auth sessions expire and re-authenticate gracefully rather than crashing.
  • Deep links and intents are validated instead of blindly trusted.
  • No debug endpoints or test menus left reachable in the release build.

How many devices do I need for testing?

You do not need every device on the market. Start from your users' devices and OS versions in analytics, then add the oldest supported OS version and one low-end device. Emulators cover many cases but miss hardware-specific issues.

Which bugs do testers most often miss?

Interrupted flows and poor network conditions. Test going offline in the middle of a task, switching back to online, and a request that fails halfway through.