Practical guide 7 min read
A mobile app testing checklist is a release-specific record of the user journeys, devices, failure conditions and acceptance evidence that must be reviewed before shipping a build. It should show what was tested, the expected behaviour, what actually happened and who owns unresolved risks—not simply say “QA completed”.
This guide is for business owners, product teams and agency reviewers preparing an Android or iOS release. It covers practical QA and user acceptance testing (UAT), not a security certification or a guarantee of app-store approval. Start with the app development planning checklist if the features and responsibilities are not yet agreed.
1. Agree the release and test environment
Record the app version and build number, backend environment, supported platforms, test accounts and features included in this release. Use authorised test data and sandbox integrations where available. Avoid real customer records or live payments merely to demonstrate that a flow works.
Choose a device matrix that reflects the intended audience: supported OS versions, screen sizes, typical hardware capability and connection conditions. Include representative physical devices, not only emulators. Android’s core app quality guidance describes checks for state preservation, compatibility, accessibility, stability and permissions, alongside a representative test environment.
For iOS beta distribution, Apple’s TestFlight guidance explains build sharing, tester groups and feedback collection. Tell testers which build and tasks to review. Beta feedback does not replace the final release decision or store review.
2. Run the mobile app testing checklist
Turn each relevant category below into named test cases. Mark an item not applicable only with a reason. An app without payments does not need a payment test, but an app with payments needs more than a screenshot of a successful checkout.
- Install and update: check a clean installation and an upgrade from the supported previous release. Confirm that existing settings and saved data behave as intended after the update.
- Core user journeys: complete the important task from beginning to end, including its backend result. For a booking app, verify the booking record and confirmation—not only the final screen.
- Authentication and account recovery: test valid and invalid sign-in, expired sessions, password recovery where provided and logout. Check that a user cannot continue viewing another user’s private data after an account change.
- Roles and authorisation: use authorised test accounts for each role. Verify both interface restrictions and backend enforcement; hiding a button alone is not an access-control test.
- Forms and validation: test empty required fields, incorrect formats, long inputs and repeated taps. Check that errors explain how to recover and that entered information is not unnecessarily lost.
- Network loss and retries: interrupt a request, restore connectivity and retry. Verify the agreed offline behaviour and check for duplicate orders, bookings or uploads. Do not assume that a timeout means the backend did nothing.
- Permissions: grant, deny and later revoke permissions used by the app. Confirm that the explanation and fallback match the feature, without blocking unrelated tasks.
- Interruptions and app state: switch apps, lock the device and return during a task. Check drafts, navigation and any pending transaction against the agreed recovery behaviour.
- Payments and integrations, where included: test sandbox success, cancellation, failure and uncertain status. Confirm reconciliation with the provider or backend. Also test unavailable APIs and invalid responses rather than silently showing success.
- Accessibility and layout: review larger text, screen-reader labels and reading order, contrast, keyboard behaviour and reachable controls. Check small screens and relevant orientations without clipped actions.
- Performance and stability: record startup, key task response and crashes on the agreed devices and data volumes. Set acceptance thresholds with the team; a universal “fast” label is not a measurable requirement.
- Notifications, links and localisation: test notification permission and tap destinations, relevant deep links, supported languages, date/time formats and timezone-sensitive tasks. Confirm that links handle signed-out users correctly.
Functional checks are not a substitute for an appropriate security assessment. Ask the responsible specialists to review sensitive-data handling, authentication, exposed APIs and integrations according to the app’s actual risk and scope.
3. Use a test-case record that can be reviewed
Copy these fields into your team’s test tracker for each case:
- Case ID and the requirement or user journey it verifies
- Build number, environment, device model and OS version
- Test role, safe test data and preconditions
- Exact steps and expected behaviour agreed before testing
- Observed result, status and timestamp
- Screenshot, recording or relevant diagnostic reference with private data removed
- Defect ID, business impact, owner and retest build
- Retest result and release decision or documented exception
Use statuses such as not run, passed, failed, blocked and not applicable. “Blocked” means a case could not be executed, not that it passed. Severity describes impact; priority describes when the team chooses to address it. Keep those decisions separate.
4. Worked example: interrupted booking submission
Illustrative scenario, not a client case study: a booking app sends a request, but connectivity drops before the user receives a response. The expected behaviour must be agreed with the product and backend teams before this becomes a pass/fail test.
| Case | Action | Expected behaviour to agree | Evidence to record |
|---|---|---|---|
| Booking-01 | Submit once with a stable connection | One booking record and a matching confirmation | Test booking reference, backend record and screen |
| Booking-02 | Disconnect after submission; reconnect and retry | Resolve the original request without creating an unintended second booking | Request reference, resulting records and recovery message |
| Booking-03 | Leave the app during confirmation and return | Show the correct current booking state, not a stale success or failure | Build/device details, steps and observed state |
Do not pre-fill the observed result with the expected result. Run the case, inspect both app and backend evidence, then record what happened. If the product does not yet define retry behaviour, log that as a requirement decision rather than guessing.
5. Separate QA, UAT and the release decision
QA checks implementation behaviour and defects. UAT asks whether business users can complete the agreed operational tasks. Release approval considers the evidence, unresolved risks and readiness of support and rollback arrangements. One person’s successful walkthrough does not establish all three.
- Assign technical reviewers for the build, integrations and defect retests.
- Ask business users to test realistic exceptions as well as routine tasks.
- Confirm who may accept a known limitation and document its user impact and follow-up owner.
- Do not label the release approved while critical journeys remain untested or unresolved blocking risks remain unassessed.
Before distribution, verify the correct build, environment settings, store information, support contact, monitoring access and the agreed recovery plan. A rollback may involve more than reinstalling an older app when backend changes are involved. After launch, use the mobile app maintenance checklist to plan monitoring and follow-up responsibility. For cross-market releases, also review the app localisation checklist.
Frequently asked questions
Is testing on one phone enough?
One phone can reveal defects, but it does not establish compatibility across the supported audience. Agree representative devices, OS versions and connection conditions, and record which combinations remain untested.
Can automated testing replace UAT?
Automation helps repeat known checks. Business acceptance still needs people who understand the intended workflows and exceptions. Use both where appropriate rather than treating either as complete evidence by itself.
Should Android and iOS share one checklist?
They can share business journeys and acceptance criteria, but platform-specific permissions, navigation, notifications, devices and distribution need separate execution records.
Does a passed checklist guarantee app-store approval?
No. Store review is a separate process. The checklist records testing evidence for the agreed release; it is not proof of every policy requirement or a promise of approval.
What information should a failed test include?
Include the build, environment, device/OS, steps, expected and observed results, safe evidence, business impact and defect owner. Record the retest result on the corrected build before closing the issue.
Planning app delivery? Discuss requirements, supported devices, testing responsibility and handover with our mobile app development team, or send an app project enquiry. Testing scope and specialist assessments are confirmed in writing; this guide does not imply that every check is included in every project.
Primary guidance reviewed 2 October 2026: Android core app quality and Apple TestFlight. Recheck current platform documentation when preparing your release.
Related Blogs
