Test Cases for Mobile App: Complete QA Checklist

The quickest way to produce weak mobile test cases is to copy a generic list into a spreadsheet and mark every row “Android/iOS.” A useful case names the state that makes mobile behavior risky: this OS, this permission history, this network transition, this app version, and this interruption point.

The matrices below are a starting set, not a promise of complete coverage. Select rows according to the product's journeys and supported capabilities, then add expected results precise enough that another tester can decide whether the build passed.

Define the Test Case Context

Every executed case should record more than steps and an expected result. At minimum, capture:

• app build and distribution source;
• device model, OS version, and available storage;
• fresh install, upgrade, or previously used state;
• account role and relevant test data;
• network type and any transition during the case;
• permission state before launch;
• expected client, server, and analytics outcome where relevant;
• cleanup or recovery needed after execution.

For example, “Verify photo upload” is not repeatable. “On a lower-memory Android device, deny photo-library access on first request, choose the in-app recovery action, grant selected-photo access in Settings, and upload one supported image” identifies the state changes and expected path.

Prioritize by failure impact and likelihood. A rare layout issue on an old tablet is not equal to duplicate payment after reconnection. Label cases with product risk, not only high, medium, and low execution priority.

Installation, Upgrade, and Launch Cases

Users do not all arrive from a clean install. Upgrade and restoration paths carry old databases, credentials, feature flags, and permission decisions.

For APP-02, install the actual released predecessor and create data before upgrading. Two fresh internal builds do not reproduce a real migration path. Verify database values through the UI and, where possible, a diagnostic or API surface.

Authentication, Inputs, and Account State

Mobile input behavior changes with keyboard, autofill, password managers, copy and paste, biometric prompts, and session lifecycle.

Test the primary fields with long names, Unicode, apostrophes, leading and trailing spaces, and locale-specific input only where the product accepts such data. Expected normalization must come from requirements, not from a tester's assumption.

For one-time passwords, cover delayed delivery, expired code, reused code, app backgrounding while retrieving the code, and autofill. Do not log real codes or personal phone numbers in test evidence.

Permissions and Device Capability Cases

Permission testing is a sequence. The first denial, repeated denial, “do not ask again” behavior, limited access, and later revocation can produce different screens.

Do not install a test helper that automatically approves every system dialog. An unexpected permission request is itself a defect. Verify that the app asks for only declared capabilities and that denial does not break unrelated journeys.

Android and iOS wording, timing, and available permission states differ. Share the business expectation, such as “user can continue without location,” but keep platform-specific steps and assertions where the operating systems diverge.

Network, Offline, and Synchronization Cases

The most revealing network cases change connectivity during a state-changing operation, not only before the screen opens.

Inspect server state for NET-03 and NET-06. A client message alone cannot prove whether a payment, booking, or message was created. Repeat reconnection and retry actions to detect missing idempotency.

For offline queues, verify ordering, cancellation, edit-after-queue, logout with pending work, and account switching. Data queued under one user must never be uploaded under another.

Interruptions, Navigation, and Notifications

Mobile journeys compete with the operating system and other apps. Execute interruptions at meaningful boundaries.

For notifications, validate foreground presentation, badge count, grouping, action buttons, duplicate delivery, expiration, and privacy on the lock screen. A correct notification that opens the wrong tenant or stale record is still a serious failure.

Deep links need authentication and authorization checks after routing. Test a valid resource owned by another account, not only a syntactically invalid URL.

Usability, Accessibility, Performance, and Privacy

Some important checks are observations rather than pass/fail scripts. Give them explicit evidence and conditions.

Set performance budgets from product expectations and representative devices. One manual timing is not a benchmark. Capture repeated measurements, build, device temperature, network, and readiness definition.

For security, verify server authorization, token expiry, secure local storage, logging, screenshots where restricted, clipboard behavior, and account deletion. Perform intrusive testing only in an authorized environment.

Select Cases for Automation and Release

Automate cases that are stable, repeated, valuable across builds, and observable through supported tooling. Good candidates include launch, login, critical navigation, core transaction smoke, API-backed data setup, and selected offline recovery. Keep visual judgment, exploratory interruption combinations, early feature behavior, and hardware feel in manual sessions.

Before release, choose a risk-based subset rather than running every row blindly:

• one fresh install and every supported upgrade path;
• critical journeys on representative Android and iOS devices;
• denial and revocation for every high-risk permission;
• a network loss during the most important mutation;
• background, process death, and session expiry recovery;
• notification and deep-link routing for each account state;
• accessibility pass through the primary journey;
• crash, analytics, privacy, version, and production configuration checks.

Your next action is to take the product's three most expensive failure journeys and assign five context variations to each: installation history, permission state, network transition, interruption, and device class. Write exact expected client and server outcomes for those 15 cases. That focused set will find more release risk than importing hundreds of context-free rows into a test-management tool.