A mobile checklist helps keep important risks visible among dozens of screens and devices before a release. It connects each check to a specific action and an observable result. "Check the network" is too broad; "disconnect after submitting an order and verify that retrying does not create a second order" can uncover a defect.
Use this material as a starting point to adapt. A banking app, media player, and habit tracker need different depth and emphasis. A good checklist develops from the product, analytics, release changes, and previous incidents.
Define the scope of the run
Before testing, record the version and build number, API environment, installation method, feature flags, and test accounts. Create a short device matrix: a key OS version, the minimum supported configuration, a popular screen size, and a device with limited resources. Base the selection on users and risks, and explicitly identify omissions.
Separate smoke testing from extended regression testing. Smoke testing establishes whether a build is usable for further work and whether essential flows pass. It does not replace data migration checks or testing after several hours of use.
Installation, updates, and first launch
Check a clean installation and an update from a supported previous version. Before updating, create realistic app data: a draft, settings, and offline objects. After the update, they should be preserved or migrated according to the requirements.
On first launch, check onboarding, language selection, required consent, and access to the main screen when optional permissions are denied. After uninstalling and reinstalling, check data restoration according to platform and product rules; a server account that still exists does not by itself mean the app failed to uninstall.
Critical user flows
Identify several actions that bring people to the product: signing in, searching, placing an order, sending a message, or viewing a ticket. For each, check a successful outcome and at least one failure state.
- →The action actually changes server data, and signing in again displays the saved state.
- →An empty list explains the next step, and errors allow users to continue.
- →Double taps and repeated submissions do not create prohibited duplicates.
- →The keyboard, long text, and system panels do not obscure a required action.
Verifying the outcome matters more than the number of screens opened. A correctly displayed toast does not establish that a request was saved.
Network and offline states
Check launch without a network, connection loss during reads and writes, slow responses, reconnection, and switching from Wi-Fi to mobile data. Clarify expected behavior for queued local operations and conflict resolution rules.
For an operation with side effects, determine what happens if the server completes the request but the client never receives the response. The screen should neither report unverified success nor force the user to repeat the action indefinitely. After reconnection, compare local and server state and check for duplicates.
Lifecycle and system interruptions
Background the app while a form is open, reopen it, lock the device, and return after the session expires. Test screen recreation and process termination separately from ordinary backgrounding: their recovery conditions differ.
Requirements may call for preserving drafts while hiding sensitive data. The system must not lose a confirmed operation or continue it with outdated permissions. Also check an incoming call or system dialog during audio recording, payment, or file upload if the product supports that scenario.
Permissions, notifications, and external navigation
Check granting, denying, and later revoking permissions the app uses. The app should respond clearly when camera, location, or notification access is unavailable. Adding unused permissions to the checklist simply for completeness is unnecessary.
For push notifications, check foreground, background, and notification-driven launch. For deep links, test an installed app, an expired session, an unavailable object, and opening the link again. A notification must not display another user's data after an account switch, and navigation must not bypass access checks.
Data, security, and compatibility
Use two test accounts to check switching users, logout, and access to previously opened private screens. Confirm that caches, search, and push notifications no longer expose the previous user's data. Diagnostic logs and reports must not contain real tokens or user secrets.
Check supported locales, time zones, and date formats in relevant scenarios. Crossing midnight is especially useful for bookings, schedules, and daily limits. Repeat the riskiest scenarios on additional devices, taking the particular release change into account.
Accessibility, speed, and stability
Follow the main flow using TalkBack or VoiceOver, enlarged text, and the agreed system settings. Assess button reachability, focus order, and error messages. Automated scanners complement manual testing.
For performance, compare cold launch and the main operation against an accepted baseline version in the same environment. Record the measurement method and several repetitions. Check freezes, crashes, memory growth after repeated actions, and activity after backgrounding; a subjective "seems fast" is insufficient.
Practical example: delivery app smoke test
Suppose the team agrees on five mandatory checks for a new build: update, sign-in, cart, order confirmation, and opening an order from a notification. On the primary device, update the previous version with a saved address, sign in, add one item, place a test order, and open its notification.
Expected result: the address is preserved, the amount matches at every step, exactly one order is created, the notification opens that order, and no crash occurs. Separately repeat confirmation with a lost response followed by network recovery. On a second device, check sign-in and order completion. This run has clear boundaries; the number of passed items does not turn it into a full regression test.
How to report results
For each item, use Passed, Failed, Blocked, or Not Run, adding the environment and a defect link. Blocked means testing was not possible; it is not a pass. List blocking problems and uncovered risks in the report, such as an update on the minimum OS version that has not yet been checked.
A checklist is useful when it supports a decision about a build. Maintain it after incidents and product changes, remove duplicates, and automate stable, repeatable checks. Every item should explain exactly what to observe and why it matters.
Further reading
Turn the checklist into a feature × platform × state matrix
Choose devices from the supported OS range, real product usage when available, and risks such as memory pressure, small screens and hardware features. Without product analytics, a three-device proposal is a risk-based hypothesis, not measured market coverage: one oldest-supported Android configuration, one current Android configuration from a different vendor, and one supported iPhone configuration. Add more iPhone OS/screen variants when the support range or feature risk warrants it.
Feature Platform/state Action Expected observation Evidence
Draft form Android background/return Enter text, switch apps, return State follows agreed save rule; no duplicate submit Build + video
Draft form iOS inactive/background/return Interrupt editing, return State follows agreed save rule Build + video
Camera Each platform; permission denied Invoke feature and deny request Usable fallback; clear explanation; no crash Permission state + video
Saved list Each platform; offline/reconnect Load, disconnect, refresh, reconnect Cache and retry follow requirements Network trace + UI
Deep link Each platform; cold/warm start Open link while signed in/out Correct destination or safe sign-in flow Link + session state
Upgrade Each supported upgrade path Install new build over prepared old state Required data preserved and migrated Old/new build + data diffDo not assume Android activity callbacks and iOS scene transitions are interchangeable. Android activities can be recreated; iOS foreground/background behavior follows its scene or app lifecycle. Record the actual OS, lifecycle action and observed recovery. Permission denial must be tested separately from permission revocation in settings; the exact options depend on OS version and permission type.
For every row record Pass/Fail/Blocked/Not run, exact device and OS, app build, starting state and a sanitized evidence link. A simulator run alone does not establish behavior for a real camera, notification delivery, radio transition or device memory pressure. Select real-device checks based on the feature risk rather than asserting all configurations are covered.