Mobile App Testing Checklist

Mobile app testing has to cover more than whether the features work. The same build runs on hundreds of device models, several OS versions, slow and switching networks, and phones that get a call in the middle of a checkout. A useful mobile app testing checklist therefore has four parts: the test types (functional, UI, compatibility, network, performance, security, accessibility, store compliance), a device matrix drawn from your real users, a list of checks for each phase from sprint to store submission, and a decision about what to automate. This post gives you all four in a form you can paste into your own test plan.

Test types

Each type answers a different question. Skipping one leaves that question to your users.

Test type	Question it answers	Examples
Functional	Does each feature do what the scope says, including the error paths?	Sign-up, sign-in, reset, core task end to end, payments, notifications
UI and usability	Does it look right and make sense on every screen size?	Layout at small and large sizes, large text settings, dark mode, orientation, empty and loading states
Compatibility	Does it work across the devices and OS versions your users have?	Oldest supported OS, latest beta, manufacturer skins, tablets, foldables
Interruption and lifecycle	Does it survive what phones do?	Incoming call, low battery, backgrounding, being killed by the OS, notifications arriving mid-task
Network	Does it behave on bad connections?	Slow 3G, packet loss, airplane mode mid-request, Wi-Fi to cellular switch, captive portals
Performance	Is it fast and light enough?	Cold and warm start time, scroll smoothness, memory, battery drain, app size, backend response under load
Security	Does it protect data and sessions?	Encrypted storage, pinned or validated TLS, token expiry, permissions, screenshots of sensitive screens, jailbreak and root behavior
Accessibility	Can everyone use it?	VoiceOver and TalkBack labels, focus order, contrast, touch target size, dynamic type
Localization	Does it work in other languages and regions?	String length, right-to-left layout, date, number and currency formats
Store compliance	Will Apple and Google accept it and keep it listed?	Privacy labels and data safety, permission prompts, purchase rules, sign-in rules, target API level

Device matrix

You cannot test every device, and you do not need to. Build a matrix from evidence and revisit it each quarter.

1. Start with data. Use your app’s analytics, your website’s mobile analytics or your device fleet list to find the top device models and OS versions. If you have no data yet, use published market share for your country and audience.
2. Cover the extremes. The oldest OS version you support, the newest release and its beta, the smallest screen and the largest tablet, and at least one low-memory Android device, which will surface performance problems before anything else does.
3. Add manufacturer variety on Android. At least one device each from the two or three manufacturers most common among your users, because battery managers, camera APIs and permission dialogs differ between them.
4. Include the odd ones your app depends on. Rugged scanners for a warehouse app, iPads for a clinic, a foldable if your users have them, a Watch if you ship a companion.
5. Split physical and cloud. Keep the core matrix on physical devices in a lab and run the long tail on a cloud device farm for each release.

A workable matrix for a consumer app is often a dozen physical devices plus cloud coverage; a workforce app on a managed fleet may need only the fleet’s models, but every one of them on every release.

Checklist by phase

Every sprint

• Unit tests pass on every merge; coverage does not fall.
• Each new feature has a functional test on at least one iOS and one Android device.
• A build goes to internal testers through TestFlight or Google Play internal testing.
• Crash reporting shows no new crash signatures from the latest build.
• UI reviewed at the smallest supported screen and with large text enabled.
• Permissions requested only when a feature needs them, with a clear reason shown.

Before each release

• Full regression suite (automated plus a manual pass of the core task) across the device matrix.
• Interruption tests: incoming call, low battery warning, OS kills the app in the background, notification tapped mid-task, device rotated mid-form.
• Network tests: slow connection, loss of signal during a request, switch from Wi-Fi to cellular, offline mode and sync if the app has one.
• Performance: cold start on the slowest device in the matrix, scroll through the longest list, memory after ten minutes of use, app size compared with the previous release.
• Security: data at rest encrypted, no sensitive data in logs or screenshots, session expiry and sign-out behave, deep links validated, dependencies scanned for known vulnerabilities.
• Accessibility: VoiceOver and TalkBack can complete the core task; contrast and touch targets meet guidelines.
• Upgrade test: install the previous release, add data, upgrade to the new build, confirm data and sign-in survive.
• Release notes, version number and build number updated.

Before store submission

• Privacy policy URL live; Apple privacy labels and Google Data safety form match what the app does.
• Purchase flows use store billing where required; sign-in flows comply with each store’s rules (for example, offering Sign in with Apple when third-party sign-in is offered on iOS).
• Android target API level meets Google’s current requirement; iOS built with the required SDK.
• Screenshots and preview video match the submitted build on each required device size.
• Demo account and review notes allow the reviewer to reach every screen.
• Age rating questionnaire answered accurately; content rating for Google Play complete.
• Signed with keys and certificates held in your organization’s name and backed up.
• Phased rollout configured so the release reaches a percentage of users first.

After release

• Watch crash-free rate and reviews for the first days; pause the rollout if either moves the wrong way.
• Compare performance and engagement metrics with the previous release.
• Log issues found in production back into the regression suite so they are caught next time.

Automation

Automate what runs often and changes rarely; test by hand what needs judgment. In practice:

• Unit tests for business logic, data mapping and validation: fast, run on every commit.
• Component and widget tests for screens in isolation: Jest and React Native Testing Library, Flutter widget and golden tests, XCTest and Compose testing for native apps.
• End-to-end tests for the core task and sign-in on real devices: XCUITest and Espresso natively, Detox or Maestro for React Native, Flutter integration tests, or Appium across any stack. Keep this suite small and reliable; a flaky end-to-end suite gets ignored.
• Device farm runs on a cloud service for breadth across the long tail of devices on each release candidate.
• Performance baselines captured automatically (start time, memory, frame drops) so regressions show up as numbers.
• Manual exploratory testing for usability, accessibility, interruption scenarios and anything new, by a tester who did not write the code.

Wire the automated layers into the build pipeline so a release candidate is only produced when they pass, and treat the end-to-end suite as production code with an owner. The broader question of what to automate and how to buy testing well is covered in QA outsourcing and test automation.

Where PS3G fits

PS3G runs a testing center of excellence that provides mobile app testing services for apps we build and apps built elsewhere: compatibility and interoperability across a device matrix, carrier and network testing, functional and regression testing, automation on every release, performance and security testing, with our white papers on mobile development and testing having been selected for the StarWest software testing conference. The same practice tests every release inside our mobile app development services, and it tests our own published apps, including the patient and doctor apps of our HIPAA-compliant EHR and telehealth platform, DocVilla. Engagements scale from a one-off pre-release test pass to a standing test team, for organizations of every size.

Related reading

• How to Build a Mobile App for Your Business: From Idea to App Store
• QA Outsourcing and Test Automation: Get Value, Not Reports
• Software testing services at PS3G

Frequently asked questions

How many devices should a mobile app be tested on?

Enough to cover your users, drawn from analytics or your device fleet rather than from a generic list. A typical consumer app matrix is around a dozen physical devices covering the most common models, the oldest and newest OS versions, the smallest and largest screens and a low-memory Android phone, with a cloud device farm covering the long tail on each release.

What is the difference between testing on simulators and on real devices?

Simulators and emulators are fine for development and for most unit and UI tests, but they do not reproduce real hardware performance, battery behavior, cameras, Bluetooth, push notifications, carrier networks or manufacturer customizations. Release testing should run on physical devices for the core matrix, with a cloud device farm providing breadth on real hardware.

Which mobile tests should be automated?

Unit tests for logic, component tests for screens, a small and reliable end-to-end suite for the core task and sign-in, and performance baselines that run on every release candidate. Usability, accessibility, interruption scenarios and new features benefit from manual exploratory testing by someone who did not write the code. Automate for repetition, test by hand for judgment.

What do app stores check that testing should cover?

That privacy labels and data-safety forms match the app’s behavior, that purchases and sign-in follow store rules, that permissions are requested with a reason, that the app targets a current OS level, that screenshots match the build and that the reviewer can reach every screen. Checking these before submission avoids most rejections and most later policy removals.

How often should the device matrix be updated?

Quarterly, and whenever a major OS version ships. Re-read your analytics, drop devices that have fallen out of use, add new models that have appeared and move the “newest OS” slot to the current beta so you see breaking changes before your users do. Managed fleets change on their own schedule, so tie the review to the fleet’s refresh cycle.