Mobile App Testing Checklist: What to Check at Each Release Stage

A mobile app testing checklist is an ordered list of checks for one specific build, where every line states what counts as a pass and who owns the result. It covers Android and iOS, and it runs from the moment a build arrives until the release has been in users' hands for a few days. A longer list is rarely what a team is missing. What usually goes wrong is that nobody agreed which lines a person must judge and which lines a machine can repeat, so the same tester ends up hand-checking a login screen for the fortieth time while the new checkout flow gets a five-minute glance. This guide fixes that by labelling every item.

What is a mobile app testing checklist?

Think of it as a release decision aid. Each line names one verification, its pass condition, and the role that signs it off. It is not a test suite, because it does not contain the steps of every test. A planning document is a different artifact too. An iOS test plan sets scope, environments, schedule and responsibilities for a release. The checklist is the shorter thing a QA lead actually ticks against build 4.12.0 (318) on a Tuesday afternoon, with evidence attached to each tick.

Each line in the stages that follow ends with one of three tags in brackets:

• Judgement: a person decides. Exploration, usability, visual feel, screen reader experience and store copy belong here.
• Repeatable: the expected result is explicit and the screen is stable, so the check is worth automating once it stops changing.
• Both: automate the mechanical half, and keep a person on the experience half.

If you need a refresher on where functional, compatibility and non-functional work sit, our overview of types of mobile app testing maps them out.

How to use this checklist

Work through the stages in order, because each one blocks the next. A build that fails smoke never reaches regression, and a release candidate with an open accessibility blocker never reaches the store.

The automation rule is simple. Automate an item when its expected result can be written down without debate, the flow is unlikely to change for the next few releases, and it runs often enough to repay the upkeep. Anything else stays with a skilled tester, and that is not a lesser job.

To keep things concrete, every stage follows one fictional release: a food-ordering app shipping a redesigned checkout screen together with a brand new promo code field. The same release produces both kinds of items. "Does the new promo flow make sense to someone ordering for the first time?" is Judgement. "A signed-in user adds a pizza, applies the code SAVE10 and sees the discounted total on Android and iOS" is Repeatable.

Stage 1: Scope and build intake

Before anyone taps a screen, settle what is being tested and on which hardware.

• Release notes list every changed area, including the new checkout and promo field [Judgement]
• Critical journeys are ranked by risk, with ordering and payment at the top [Judgement]
• Device and OS matrix is picked from real usage data and the support policy, and includes the oldest supported OS, a small screen and a mid-range Android phone [Judgement]
• Test accounts exist and app data can be reset to a known state between runs [Repeatable setup]
• The build under test is the release-type build you plan to ship, with version and build number recorded [Repeatable]

Android and iOS differences to plan for

Some platform differences change the checklist itself. Android has a system back action (button or gesture), while iOS relies on in-app navigation and edge swipes. Permission prompts appear at different moments and with different wording. Software keyboards cover different parts of the screen, which matters for a promo field near the bottom of checkout. Distribution also differs: iOS testers usually install from TestFlight, Android testers from a Play testing track. Write those differences into the items rather than assuming one platform behaves like the other.

Stage 2: Every build smoke checks

Smoke checks answer one question: is this build worth testing further? They should be short enough to run on every build without anyone groaning.

• App installs and cold launches without a crash [Repeatable]
• Sign in and sign out both work with a standard test account [Repeatable]
• The core transaction completes, so the order total matches the cart after a valid promo is applied [Repeatable]
• Main navigation reaches every top-level tab or screen [Repeatable]
• Crash reporting receives a deliberate test event from this build [Both]

These five lines are the first candidates for automation, because they repeat on every build and their pass conditions never move. Teams usually run smoke checks in CI/CD so that a broken build is caught before a person spends time on it. Smoke and sanity are close cousins: smoke confirms a fresh build is stable enough to test, while sanity confirms a narrow fix did what it promised. For that narrower case, see our guide to sanity testing after a hotfix.

Stage 3: Feature change validation

This stage is where most real bugs in our fictional release will surface, because it targets what changed.

• A timed exploratory session covers the new checkout and promo screens, with notes on anything confusing [Judgement]
• Promo field rejects empty, malformed, expired and stacked codes with a clear message for each [Repeatable once stable]
• Denying location or notification permission, then granting it later from settings, leaves the app in a working state [Both]
• A push notification or deep link for "your order is ready" opens the correct order screen with the right data [Both]
• Losing connection mid checkout shows a recoverable state, and a retried payment request never creates a duplicate order [Both]

The deep link item is a good example of a split label. Whether the notification arrives depends on the environment and the push service, so a person often confirms delivery. Where the tap lands and what data it shows is fully repeatable.

One rule matters more than any single item here: do not automate a screen that is still being redesigned every sprint. Check the new checkout by hand while the layout settles, then add the Repeatable test once the design is signed off. Automating too early buys a week of broken tests and no extra confidence.

Stage 4: Release candidate regression and compatibility

Once a release candidate exists, the question changes from "does the new thing work?" to "did we break anything that used to work?"

• The full suite of previously working journeys passes on the release candidate build [Repeatable]
• The same journeys pass on every device and OS in the matrix, using physical devices for the release decision [Repeatable]
• Landscape orientation, dark mode and the largest text size do not hide or clip the checkout total or the Place order button [Both]
• Sending the app to the background, taking a call or switching apps mid order resumes on the same screen with the cart intact [Both]
• Shared Android and iOS cases use platform-specific steps wherever navigation differs [Repeatable]

Our page on mobile regression testing covers how to keep that suite lean as features pile up.

Android app testing checklist notes

Test both three-button and gesture navigation, since the back action behaves differently. Include at least one manufacturer skin beyond stock Android, because OEM changes to permissions, battery management and fonts cause bugs emulators rarely show. Add a low-memory device to catch the app being killed in the background.

iOS app testing checklist notes

There is no system back button, so every screen needs a visible way out. Permission prompts often appear only once per install, so plan for reinstalling. Apple notes that simulators do not replicate every feature or the performance of a physical device, so the release decision should rest on hardware. Our iOS app testing workflow covers the simulator versus device split in detail.

Stage 5: Release candidate non-functional checks

These checks decide whether the app is usable, safe and ready for the stores, not just correct.

• A tester completes ordering with VoiceOver on iOS and TalkBack on Android and can understand every control [Judgement]
• Tap targets on checkout meet platform guidance: Apple's 44x44 point minimum and Android's 48x48 dp minimum [Both]
• Launch time, menu scrolling and memory use on a mid-range device stay within the team's own baseline [Both]
• Session tokens sit in secure storage, logs contain no secrets and all traffic uses HTTPS [Both]
• Upgrading from the version currently in the store keeps the user signed in and preserves saved addresses [Repeatable once scripted]
• Store listing, screenshots, privacy details and permission strings match what this build actually does [Judgement]

Two cautions. First, set performance baselines from your own app and devices, measured with each platform's profiling tools, rather than copying a universal number from a blog post. A menu-heavy food app and a banking app have very different baselines. Second, the security row is a floor, not a full review. The OWASP Mobile Application Security Verification Standard (MASVS) is the reference when you need the complete picture.

Stage 6: Staged rollout and post-release

Submission is not the finish line. Keep a short block for the days after release, and give it a named owner.

• Release goes out gradually through a Google Play staged rollout or an App Store phased release where the change is risky [Judgement]
• Production smoke runs against the live build with a real but low-risk order [Repeatable]
• A named release manager watches crash reports, store reviews and support tickets for the first days, with a halt rule agreed before launch [Judgement]

On Google Play the rollout percentage does not increase by itself, and you can halt it. On the App Store, a phased release spreads the update over seven days to users with automatic updates turned on. Agree in advance what crash rate or complaint pattern triggers a pause, so nobody debates it at midnight.

Table 1: Mobile app testing checklist by release stage

Copy this table into your tracker as a starting point and replace the fictional food-ordering details with your own journeys.

Stage	Check	Pass when	Label	Evidence to keep
Intake	Changed areas listed	Checkout and promo field named in release notes	Judgement	Release notes link
Intake	Device and OS matrix chosen	Oldest supported OS, small screen and mid-range Android included	Judgement	Matrix in tracker
Intake	Release-type build recorded	Version and build number match the shipping candidate	Repeatable	Build ID
Intake	Test data resettable	Test account returns to empty cart on reset	Repeatable	Reset log
Smoke	Install and cold launch	Home menu loads with no crash	Repeatable	Run report
Smoke	Sign in and sign out	Account name shows after sign in and clears after sign out	Repeatable	Screenshot
Smoke	Core order	Total equals cart minus valid promo	Repeatable	Screenshot of total
Smoke	Crash reporting	Test event appears in the crash tool for this build	Both	Event link
Change	Exploratory session on checkout	QA lead notes no blocking confusion	Judgement	Session notes
Change	Promo code validation	Empty, expired and stacked codes each show a clear error	Repeatable	Run report
Change	Permission deny then allow	Ordering works after permission is granted in settings	Both	Video
Change	Order ready deep link	Tap opens the matching order screen	Both	Video
Change	Connection lost mid payment	One order created after retry	Both	Backend order log
Regression	Previous journeys	Full suite passes on the release candidate	Repeatable	Suite report
Regression	Device matrix	Same journeys pass on each matrix device	Repeatable	Per-device report
Regression	Large text and dark mode	Total and Place order stay visible	Both	Screenshots
Regression	Interruption recovery	Cart intact after a call or app switch	Both	Video
Non-functional	Screen reader pass	Order completed with VoiceOver and TalkBack	Judgement	Tester notes
Non-functional	Performance	Launch and scrolling within the team's baseline	Both	Profiler capture
Non-functional	Security basics	No tokens in logs, HTTPS only	Both	Log review
Non-functional	Upgrade path	Session and saved addresses survive upgrade	Repeatable	Run report
Non-functional	Store readiness	Listing, privacy details and permission text match the build	Judgement	Review sign-off
Rollout	Production smoke	Live order succeeds on the store build	Repeatable	Run report
Rollout	Post-release watch	Halt rule checked daily by the release manager	Judgement	Daily note

Which checklist items should you automate?

Run each item through five questions before writing a test.

Question	If yes	If no
Can the expected result be written as one exact outcome?	Good automation candidate	Keep it with a tester until it can
Will the screen and flow stay the same for the next few releases?	Automate now	Check by hand until the design settles
Does it run on every build or every release?	The upkeep pays for itself	A manual pass may cost less
Does it depend on human perception, such as layout feel or screen reader clarity?	Keep a person on it, automate only the mechanical part	No obstacle to automating
Can app state and test data be reset before each run?	Runs stay independent	Fix the data setup first

Recording a journey is not the same as checking it. A test needs an explicit assertion, such as the discounted total reading the right amount. Also separate two kinds of failure. A test that fails because a button moved needs its locator repaired. A test that fails because the discount is wrong has found a real defect and must stay red until someone fixes the app.

Where QApilot fits for the repeatable items

QApilot handles the Repeatable lines of this checklist, and leaves the Judgement lines with your team. You record a journey on Android or iOS, such as adding a pizza and applying SAVE10, then add explicit checks like a text check on the order total. Cases are grouped into suites and a test plan that runs on local devices or on supported cloud providers such as BrowserStack and Sauce Labs. QApilot works alongside those device clouds rather than replacing them. Plans can be scheduled daily or triggered from your CI/CD pipeline when a new build lands.

When a locator stops matching, auto-healing tries Element ID or Accessibility ID first, then XPath and tag attributes, then a visual match, then the recorded coordinates. Healed steps are marked AI Assisted in the report, and a person decides whether to save the new locator with Update XPath. Healing keeps a run going. It does not prove the order total was correct, which is why the explicit check matters.

Shared cross-platform cases keep platform-specific steps, so an Android Go Back step can sit next to an iOS navigation step in the same case. On Android only, the crawler can also explore app paths and record them as test steps. Each execution report holds screenshots, video and logs, and you can raise a Jira issue from it. QApilot supplies the evidence; your team still owns the release decision.

Mobile app testing checklist FAQ

What should a mobile app testing checklist include?

It should cover six things in order: smoke checks for install, launch, sign in and the core transaction; validation of whatever changed in this release; regression and compatibility on a representative set of Android and iOS devices; accessibility, performance, security basics and the upgrade path; store readiness; and a watch period during a staged rollout. Every line needs a pass condition and a named owner, otherwise it is a wish list.

Which mobile app tests should be automated?

Automate checks that have one exact expected result, a flow that will not change soon and a frequent schedule. Every-build smoke journeys and release candidate regression across devices fit that description well. Exploratory sessions, usability, visual judgement, screen reader experience and store copy review are better left to people. Automated checks still need resettable test data, someone who reviews the evidence and an owner for each failure.

What is the difference between a mobile app QA checklist and a test plan?

A test plan describes scope, approach, environments, schedule and responsibilities for a product or release. A QA checklist is the short, ordered list a team ticks for one build, with a pass condition on every line. The plan decides what matters for the release, and the checklist records that each item was actually verified on that build.

Start with your smoke stage

Pick the five smoke items above, write an exact pass condition for each, and automate those first, since they run most often. Keep skilled testers on the Judgement items for whatever changed in this release. When the smoke suite is stable, move on to regression, one journey at a time.