Mobile App Testing Checklist (2026): 35 Test Cases for Android and iOS
By Chirag Ali Palsania, Founder, INNOVISCENT (Ahmedabad) · Last updated
Quick answer
A mobile app testing checklist is the set of checks you run before every release. The essentials: core journeys work end to end, the app survives interruptions and poor networks, screens look right on every size, it stays fast and stable on low-end phones, user data is secure, it is accessible, and it meets Google Play and App Store rules. Test on real devices that match the phones your users actually own.
Key takeaways
- Prioritise by risk: launch, login, payments and data loss come first.
- Pick test devices from your own analytics, and always include a low-end Android phone.
- Emulators are fine for early checks; real devices are essential before release.
- Test on slow and unstable networks, not just office Wi-Fi.
- Automate stable, repeated checks; keep usability and exploratory testing manual.
What is mobile app testing?
Mobile app testing checks that an Android or iOS app works correctly, performs well and is secure on the devices, operating system versions and networks your users have. It covers far more than web testing: phones get calls mid-task, lose signal, run low on memory and come in hundreds of screen sizes.
How do you prioritise mobile app testing when time is short?
Test by risk. If you only have a day before release, cover these in order:
- 1. The app opens and doesn't crash on your most-used devices.
- 2. Login and sign-up work, including OTP.
- 3. Money flows work: payments, UPI, in-app purchases and refunds.
- 4. No data is lost during updates, interruptions or poor network.
- 5. The main user journey completes, such as placing an order or making a booking.
- 6. Then everything else on the checklist below.
Which devices should you test on?
Build your device list from your own data, such as Google Play Console, App Store Connect or your analytics tool, instead of guessing. A practical starting list:
- The 5–8 phones your users use most, from your analytics.
- At least one low-end Android phone with limited RAM. In India, budget and mid-range Android phones make up a big part of most apps' users.
- Major Android skins: for example Samsung One UI, Xiaomi HyperOS, and phones from Vivo, Oppo or Realme, which can behave differently from stock Android.
- The oldest OS version you support and the newest one.
- A small screen and a large screen, plus a tablet or foldable if you support them.
- At least one current iPhone and one older iPhone that still runs your minimum iOS version.
Real devices vs emulators: which should you use?
Use both. Emulators and simulators are fast and cheap for early checks, but only real devices show true performance, battery, camera, sensor and manufacturer-specific behaviour.
| Factor | Emulators and simulators | Real devices |
|---|---|---|
| Cost | Free, built into Android Studio and Xcode | Buy devices or rent a cloud device lab |
| Speed to start | Instant | Slower to set up and manage |
| Performance and battery | Not realistic | Realistic |
| Camera, GPS, fingerprint, Face ID | Limited or simulated | Real behaviour |
| Manufacturer skins and quirks | Mostly not covered | Covered |
| Best for | Development, early UI and logic checks | Release testing and bug reproduction |
The mobile app testing checklist: 35 test cases
Run the full list before major releases, and the high-risk parts before every release. Each test has a simple pass rule, so anyone on the team can check it.
1. Functional testing
| # | Test case | Pass when |
|---|---|---|
| 1 | Install, first launch and onboarding | Installs from the store build, opens without a crash, and onboarding can be completed or skipped |
| 2 | Sign-up, login, OTP and logout | OTP arrives and auto-fills where supported, resend works, a wrong OTP shows a clear error, and logout ends the session |
| 3 | Core user journey end to end | The main task (for example an order or booking) completes and the data is saved correctly |
| 4 | Payments: UPI, cards, wallets and in-app purchases | Success, failure, cancel and pending all show the right status, with no double charge after returning from a UPI app |
| 5 | Push notifications and deep links | Tapping a notification, or a link from SMS, WhatsApp or email, opens the right screen in the app |
| 6 | Update from the previous version | Users stay logged in and keep their data after updating |
2. Interruptions and app lifecycle
| # | Test case | Pass when |
|---|---|---|
| 7 | Incoming call, SMS or alarm during a task | The app resumes where the user left off, with no lost input |
| 8 | App sent to the background and reopened later | The screen is restored, or reloads cleanly without errors |
| 9 | App closed by the system for low memory | It reopens without crashing and handles unsaved data sensibly |
| 10 | Permissions denied or revoked (camera, location, notifications) | The app explains why it needs them and keeps working where it can |
3. UI and compatibility
| # | Test case | Pass when |
|---|---|---|
| 11 | Small and large screens, notches and foldables | No cut-off text, overlapping buttons or hidden content |
| 12 | Portrait and landscape (if supported) | The layout adjusts and typed input is not lost |
| 13 | Large font and display size settings | Text stays readable and nothing is cut off |
| 14 | Dark mode | All text and icons stay visible and readable |
| 15 | Oldest and newest supported OS versions, and major Android skins | Features work and layouts look right on each |
| 16 | Regional languages and formats (if supported) | Hindi, Gujarati or Marathi text displays and fits; dates and ₹ amounts use the right format |
4. Performance and stability
| # | Test case | Pass when |
|---|---|---|
| 17 | Cold start on a low-end phone | The app opens within the target your team has agreed, measured on every release |
| 18 | Scrolling long lists and animations | Smooth, with no visible stutter |
| 19 | Memory use and crashes over a long session | Memory stays stable over about 30 minutes of use, with no crashes or "app not responding" errors |
| 20 | Battery and mobile data use | No unusual drain in the background; images and downloads are compressed |
| 21 | App download size | Size is tracked each release and has not grown without a reason |
5. Network conditions
| # | Test case | Pass when |
|---|---|---|
| 22 | Slow and high-latency network | Loading states show, timeouts are handled and screens never freeze |
| 23 | Going offline in the middle of an action | A clear message appears, and nothing is submitted twice when the connection returns |
| 24 | Switching between Wi-Fi and mobile data | Requests retry and the user stays logged in |
| 25 | Server errors and slow APIs | A friendly error with a retry option appears, and the app doesn't crash |
6. Security and privacy
| # | Test case | Pass when |
|---|---|---|
| 26 | Storage of sensitive data | Tokens are kept in Android Keystore or iOS Keychain; no passwords or card data in plain text or logs |
| 27 | Network security | All calls use HTTPS with proper certificate checks |
| 28 | Session timeout and login on a new device | Sessions expire as designed and old sessions can be ended |
| 29 | Sensitive screens in the app switcher (finance and health apps) | Sensitive data is hidden in previews and screenshots where your policy requires it |
| 30 | Rooted or jailbroken devices (if you have a policy) | The app behaves as your security policy says |
7. Accessibility
| # | Test case | Pass when |
|---|---|---|
| 31 | Screen readers: TalkBack (Android) and VoiceOver (iOS) | Every button and image is read out with a meaningful label, in a sensible order |
| 32 | Touch target size | Tap targets meet platform guidance: at least 48 × 48 dp on Android and 44 × 44 pt on iOS |
| 33 | Colour contrast and colour use | Text is easy to read, and information is never shown by colour alone |
8. Store readiness
| # | Test case | Pass when |
|---|---|---|
| 34 | Google Play Data safety form and App Store privacy details | They match exactly what the app collects and shares |
| 35 | Pre-release build and rollout | The final build is tested through a Play Console testing track or TestFlight, and a staged rollout plan is ready |
How do you test a mobile app on slow networks?
You don't need to travel to a weak-signal area. Use built-in tools to slow the connection down:
- Android emulator: set the network speed and latency in the emulator's cellular settings.
- iPhone: turn on Developer settings and use Network Link Conditioner, which has profiles such as 3G and very bad network.
- Proxy tools: Charles Proxy or similar tools can slow down or block specific API calls to test error handling.
- Real-world check: before a major release, try the app on mobile data in a lift, a basement or while travelling.
Which mobile tests should you automate?
| Automate | Keep manual |
|---|---|
| Login, sign-up and core journeys on every build | Usability and "does this feel right" checks |
| Regression checks across top devices | New features that are still changing |
| API tests behind the app | Exploratory testing to find unexpected bugs |
| Smoke tests on every pull request | Accessibility with real screen-reader users |
| Screenshot comparison for key screens | Real-world network and battery checks |
Automated tests should run in your pipeline on every build, with the full regression suite nightly. Our guides on what regression testing is and manual vs automated testing explain how to choose.
Which tools are used for mobile app testing?
| Tool | Type | Used for |
|---|---|---|
| Appium | Automation, open source | One test framework for both Android and iOS |
| Espresso | Automation, Android | Fast, reliable UI tests written by Android developers |
| XCUITest | Automation, iOS | Native UI tests for iPhone and iPad apps |
| Firebase Test Lab, BrowserStack, Sauce Labs | Cloud device labs | Running tests on many real devices without buying them |
| Android Studio Profiler and Xcode Instruments | Performance | Measuring start time, memory, CPU and battery |
| Firebase Crashlytics | Monitoring | Tracking crashes and errors after release |
| Charles Proxy and Network Link Conditioner | Network | Simulating slow or broken connections |
What to do after release
- Use a staged rollout so a bad release reaches only a small share of users first.
- Watch crash-free users and "app not responding" rates in Play Console, App Store Connect or Crashlytics for the first few days.
- Read new store reviews daily for the first week; users report device-specific bugs there first.
- Add a test case for every serious bug found after release, so it can't come back unnoticed.
How INNOVISCENT can help
Our QA automation team in Mumbai and Ahmedabad tests Android and iOS apps on real devices, builds Appium automation that runs in your pipeline, and checks the APIs behind your app. We also offer mobile app security testing, and our app development team builds apps with testing included from day one.
Wondering what this would cost for your app? See our software testing cost guide, or book a free 30-minute call.
Frequently Asked Questions
What should a mobile app testing checklist include?
It should cover functional testing, interruptions such as calls and backgrounding, UI on different screen sizes, performance and stability, poor network conditions, security and privacy, accessibility, and Google Play and App Store readiness.
Should I test on real devices or emulators?
Use both. Emulators and simulators are good for fast early checks during development, but test on real devices before every release, because only real devices show true performance, battery use and manufacturer-specific behaviour.
How many devices should I test a mobile app on?
Start with the 5 to 8 phones your users use most, based on your analytics, plus a low-end Android phone, the oldest and newest OS versions you support, and at least one older and one current iPhone.
Which mobile app tests should be automated?
Automate stable, repeated checks such as login, core user journeys, regression tests across top devices and API tests. Keep usability, exploratory and new-feature testing manual.
What tools are used for mobile app testing?
Common tools include Appium for cross-platform automation, Espresso for Android, XCUITest for iOS, cloud device labs such as Firebase Test Lab and BrowserStack, and Firebase Crashlytics for crash monitoring.
How do you test a mobile app on a slow network?
Use the Android emulator's network speed settings, Network Link Conditioner on iPhone, or a proxy tool such as Charles Proxy to slow down or block API calls. Also try the app on real mobile data in weak-signal places.
What is the difference between Android and iOS app testing?
Android testing has to cover many more devices, screen sizes and manufacturer skins, while iOS has fewer devices but strict App Store review rules. The core checklist is the same for both, with platform-specific checks added.