A screen can look correct while the task behind it fails. Start with sign-in and the main action, then interrupt the journey: lose the connection, close the app, or deny a permission. The app should explain what happened and avoid losing or duplicating work.
Build the QA plan from risk. Identify the journeys whose failure harms users or the business, then vary state, device, data, network, interruption, and authority around them. Combine automated checks with representative devices and human evaluation; no single tool covers the whole mobile product.
Related service: Android & iOS Application development- 01Define critical journeys, user harm, business consequence, and quality gates.
- 02Create a representative device, OS, account, permission, and network matrix.
- 03Automate stable unit, contract, integration, and high-value UI checks.
- 04Test lifecycle, interruption, offline, duplicate, degraded, and recovery paths.
- 05Verify accessibility, security, privacy, performance, and store requirements.
- 06Triage with reproducible evidence and retest the signed release candidate.
- 07Monitor production outcomes and convert findings into regression coverage.
SECTION 01
Define quality and release gates first
List the critical journeys and what correct completion means. Include data, authorization, downstream state, user feedback, audit evidence, and recovery—not only the final screen. Rank each journey by frequency, user harm, financial or data consequence, operational impact, and detectability.
Set release gates such as no unresolved critical security or data-integrity findings, successful representative-device completion of launch journeys, accurate privacy declarations, verified upgrade, active monitoring, and documented accepted risks. Project owners must define the specific thresholds; a generic checklist cannot choose them.
| Factor | Question | Testing response |
|---|---|---|
| Consequence | Could failure expose data, create an unauthorized action, lose work, or affect money or safety? | Add deeper review, negative cases, independent evidence, and stricter release gating. |
| Frequency | How often and by how many users is the journey performed? | Automate stable high-volume paths and monitor their production completion. |
| Variability | Which devices, OS versions, permissions, locales, roles, or networks change behavior? | Build representative partitions rather than one ideal configuration. |
| Change | Which code, SDK, service, rule, or platform area changed? | Target regression around the change plus its connected journeys. |
| Recoverability | Can the user retry or can staff reconcile the result safely? | Test rollback, retry, duplicate protection, support, and data repair. |
SECTION 02
Build a representative mobile test matrix
Choose device and OS coverage from supported users, analytics when available, platform requirements, form factors, hardware features, and risk. Include low-resource or smaller devices when relevant, tablets or foldables if supported, and the latest platform version. Simulators and emulators are useful for fast coverage; representative physical devices reveal camera, biometrics, sensors, notifications, battery, memory, and real lifecycle behavior.
Add account and application states: new, returning, expired, locked, partially onboarded, different roles, migrated data, no data, large data, pending offline work, and upgrade from a supported prior build. Add permission states, locale, time zone, text size, orientation, dark mode where supported, low storage, and interrupted sessions.
SECTION 03
Test functional journeys through lifecycle changes
For each critical journey, test normal completion, validation, cancellation, back navigation, interruption, background and foreground transitions, rotation or resizing where relevant, app switching, phone calls or notifications, session expiry, permission change, and process restart. Android's core quality tests explicitly include sleep, lock, app switching, and interruptions because mobile state changes are normal use, not rare edge cases.
Check that actions are not duplicated when users tap twice, retry after a timeout, reopen a deep link, or restore the app. Confirm progress and error messages are accurate, partial input is handled intentionally, destructive actions have suitable confirmation, and recovery returns the user to a truthful state.
- 01
Start the journey in each meaningful account and data state.
- 02
Interrupt before, during, and after a state-changing request.
- 03
Change network, permission, and lifecycle conditions.
- 04
Retry, navigate back, reopen, and repeat the request.
- 05
Verify client, backend, integration, and audit state agree.
SECTION 04
Verify offline, backend, and integration failures
Control network conditions rather than toggling airplane mode once. Test slow responses, lost connection, DNS or TLS failure, timeout after the server accepted a write, rate limiting, expired authentication, maintenance, partial downstream failure, and delayed notification. The app should show a safe state and avoid blind retries that duplicate consequences.
For offline workflows, verify what data is available, how freshness and pending status appear, queue persistence across restarts, ordering, idempotency, conflict resolution, attachment recovery, and reconciliation. Inspect authoritative backend and downstream records after the client reports success or failure.
SECTION 05
Test accessibility, security, and privacy as behavior
Accessibility testing should include screen-reader navigation, labels and state, focus order, dynamic text size, contrast, non-color cues, touch targets, motion alternatives, keyboard or switch input where relevant, captions or transcripts for media, and error recovery. Apple recommends auditing interfaces with accessibility tools, while Android quality guidance includes accessibility within the app experience. Human testing remains important for critical journeys.
Use a defined security baseline. OWASP MASVS organizes controls for storage, cryptography, authentication and authorization, network communication, platform interaction, code quality, resilience, and privacy. Test the backend separately for object and action authorization. Verify that production data behavior and third-party SDKs match privacy and store declarations.
Sensitive storage
Inspect local files, databases, logs, backups, screenshots, clipboard, notifications, and caches.
Access boundaries
Attempt other users' records, roles, objects, functions, deep links, and administrative actions.
Permission behavior
Test denial, revocation, limited access, later enablement, and clear purpose at the point of use.
Third-party behavior
Inventory SDK collection, sharing, network destinations, configuration, and removal or opt-out paths.
SECTION 06
Verify performance and the signed release candidate
Measure startup, interaction responsiveness, memory, battery-sensitive work, network usage, file and media handling, and critical journey latency on representative conditions. Look for trends and user impact rather than optimizing one benchmark. Test data growth and long sessions when the product creates local or cached records.
Run the final smoke and critical regression checks on the exact signed artifact using production-like services and store configuration. Verify metadata, deep links, notifications, purchases where applicable, analytics, crash reporting, feature flags, privacy links, support, account deletion, reviewer access, versioning, and upgrade. Record the build identifier and evidence used for the release decision.
| Evidence | What it should identify | Owner |
|---|---|---|
| Scope and risk | Critical journeys, supported matrix, changes, priorities, and accepted exclusions. | Product and QA |
| Test results | Build, environment, device/OS, data, steps, result, finding, and retest. | QA and engineering |
| Security and privacy | Control scope, findings, disposition, declarations, permissions, and SDK review. | Security/privacy owner |
| Production readiness | Services, migration, monitoring, backup, support, rollback, and reviewer access. | Technical and operations owners |
| Release decision | Approvers, remaining risk, rollout, stop conditions, and communication plan. | Accountable release owner |
SECTION 07
Turn production findings into regression coverage
After release, compare critical journey completion, crashes, freezes, API failures, support reports, store feedback, device and version patterns, and data reconciliation. Protect privacy by collecting only necessary diagnostic information with appropriate disclosure and access.
For every meaningful escaped defect, add the smallest reliable prevention: a unit, contract, integration, UI, security, migration, monitoring, or runbook check. Review flaky tests rather than allowing them to normalize failure. Quality improves when production evidence changes the system and its test model.
SECTION 08
Frequently asked questions
What should be tested in a mobile app?
Test critical journeys, devices and OS versions, install and upgrade, account states, permissions, lifecycle interruptions, networks and offline behavior, accessibility, security, privacy, backend and integrations, performance, store configuration, monitoring, and recovery.
Are simulators enough for mobile app QA?
No. Simulators and emulators provide fast repeatable coverage, but representative physical devices are needed for hardware, performance, notifications, biometrics, cameras, sensors, battery, memory, and real operating-system behavior.
How many devices should a mobile app be tested on?
There is no universal count. Select representative partitions from supported users, OS versions, screen and device classes, hardware features, observed usage, platform requirements, and risk. Add targeted devices when production evidence reveals a pattern.
When is a mobile app ready to launch?
It is ready when the accountable owners have evidence that critical journeys pass on the supported matrix, high-consequence risks are resolved or explicitly accepted, declarations are accurate, production services and support are ready, and rollout and recovery are controlled.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Core app quality guidelinesAndroid Developers
- AccessibilityApple Developer
- App Review GuidelinesApple Developer
- OWASP Mobile Application Security Verification StandardOWASP Foundation
- Build an offline-first appAndroid Developers
- Secure Software Development Framework (SP 800-218)National Institute of Standards and Technology
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy