Mobile App Testing: Types, Checklist and Tools

A team ships version 4.12 on a Tuesday. By Thursday the crash dashboard shows a single failure repeating: the app dies when a call arrives during checkout, but only on one manufacturer's Android build. The web app has never had a bug shaped like that, because a web page has never had to survive a phone call. The fix takes two hours. Getting it in front of users takes four days, because the store review sits in the middle.

That gap is what makes mobile app testing a different discipline rather than a smaller screen. This guide covers the failure modes that only exist on a device, and the types of testing that address them. It gives you a checklist to run before a release. It also covers how to pick a device matrix without buying every phone, and how to document mobile cases so coverage stays auditable.

Why mobile is not web testing with a smaller screen

Five structural differences create failure modes that have no web equivalent.

Fragmentation is real, not a slogan. A web app targets a handful of browser engines. A mobile app targets thousands of device models, several live OS versions, and manufacturer skins that change system behaviour. A layout that is perfect on one flagship can clip on a device with a different aspect ratio and a taller status bar.

Interrupts happen constantly. A phone call, a notification, an alarm, a low battery warning, a permission dialog, the user switching apps for 40 minutes and coming back. Each one suspends your app mid-task. On the web, nothing interrupts a form except the user.

The network is unreliable by default. Not slow, unreliable. A session moves from wifi to cellular in a lift, loses signal in a tunnel, and returns. Requests get retried, duplicated or abandoned. A payment submitted twice because of a lost response is a mobile bug that web apps rarely see.

Install and update are real code paths. A fresh install and an upgrade from three versions back run different code. Local databases get migrated. Cached tokens survive or do not. Most teams test the fresh install because it is easy, and ship the migration untested.

The store sits between you and your users. You cannot hotfix in twenty minutes. Review takes as long as it takes, and some users will stay on an old version for months. Every release decision has to assume old clients are still out there.

The types of mobile testing that earn their place

• Functional. The feature works as specified on a supported device. The baseline, and the part most similar to web testing.
• Compatibility. The same case run across the device and OS combinations you support. This is where fragmentation gets caught, and it is mostly a coverage problem rather than a case design problem.
• Interrupt testing. Incoming call, notification, alarm, backgrounding, low battery, low storage, permission revoked while the app is open. Mobile specific and routinely skipped.
• Installation and update testing. Fresh install, upgrade from the previous version, upgrade from several versions back, reinstall over existing data, and a downgrade if your store allows it.
• Performance. Cold start time, memory under a long session, battery drain, and behaviour on a device with 400 MB of free storage.
• Usability. Thumb reach, tap target size, one-handed use, dark mode, text scaling for accessibility, and whether an error is readable in sunlight.
• Localisation. Longer German strings breaking a button, right to left layouts, date and currency formats.
• Security adjacent. Whether data is written to unprotected local storage, and whether tokens survive an uninstall. Mention it here, then treat real security work as its own programme with its own tooling.

A mobile app testing checklist

Run this before a release. It is grouped by risk area rather than by feature, because the risks are what mobile adds.

Interrupts and lifecycle

• Receive a call during the most important flow, then return to the app.
• Background the app for 30 minutes mid-form, then resume.
• Rotate the screen during a loading state.
• Lock and unlock the device while a request is in flight.
• Revoke camera or location permission from settings while the app is open.
• Trigger a low battery warning and a low storage warning.

Network conditions

• Complete the primary flow on a throttled connection.
• Kill the connection mid-request and restore it.
• Switch from wifi to cellular during an upload.
• Use the app fully offline, then reconnect and confirm nothing duplicated.
• Confirm a timed-out payment cannot be submitted twice.

Install, update and data

• Fresh install on a clean device.
• Upgrade from the current production version.
• Upgrade from a version at least three releases old.
• Confirm local data survives the upgrade, including any database migration.
• Uninstall and reinstall, and check what is left behind.
• Confirm an old client version still works against the current backend.

Device and OS coverage

• Oldest OS version you claim to support.
• Newest OS version, including the current beta if a release is near.
• One low-memory or budget device, not only flagships.
• Smallest and largest screen sizes in your matrix.
• A tablet, if you say you support tablets.

Performance and usability

• Cold start time on the slowest supported device.
• Memory after 20 minutes of continuous use.
• Battery drain during a typical session.
• Text scaled to the largest accessibility setting.
• Dark mode on every screen, including modals and error states.

Store readiness

• Permissions requested match what the store listing declares.
• Privacy disclosures match what the app actually collects.
• Screenshots and metadata match the shipped build.
• The forced update path works, in case you need to retire an old client.

Much of that list is exploratory in character rather than scripted, so capture what you find without turning every probe into a permanent case. Documenting exploratory testing without the bloat covers how.

Real devices or emulators

This argument gets treated as a matter of principle when it is really a matter of cost and coverage.

Emulators and simulators are for speed. They are excellent for logic, layout, navigation and the hundreds of checks a developer wants feedback on within two minutes of a commit. They cost nothing per run and they can be spun up in parallel.

Real devices are for anything that touches the physical world. Camera, biometrics, GPS, bluetooth, push notifications, the actual network radio, battery behaviour, and the manufacturer skin sitting between your app and the OS. Final release sign off belongs here too, because the bug in the opening paragraph only exists on a real handset.

Device clouds sit in between, giving you real hardware without a drawer full of phones. The tradeoff is queue time and cost per minute, which is why teams run most checks on emulators and reserve the cloud for the matrix pass.

How to decide a device matrix

Do not try to cover the market. Cover your users, then add the edges deliberately.

1. Start with your own analytics. List device models and OS versions by session share. Most apps find that 6 to 10 combinations cover roughly 80 percent of real sessions.
2. Add the floor. The oldest OS version you publicly support, on a device that is genuinely slow.
3. Add the ceiling. The newest OS version, and its beta when a platform release is weeks away.
4. Add one constrained device. Low memory, small storage, cheap chipset. Half of your performance bugs live here.
5. Add one of anything you claim. A tablet, a foldable, a smartwatch companion. If the store listing says you support it, something has to run on it.

A concrete version of that: six devices covering 78 percent of sessions, plus an old budget Android, plus the current iOS beta. Eight combinations, reviewed once a quarter against fresh analytics. That is a matrix a real team can maintain.

Be honest about the cost of each one you add. If a full regression pass takes 40 minutes on one device, eight devices is over five hours of machine time, and every added combination extends the release. Deciding what deserves the full pass and what gets a smoke run is the same triage as smoke, sanity and regression runs on any other platform.

Working with app store review

Store review turns every release into a scheduled event, so plan for it rather than being surprised by it.

• Assume the lead time, do not hope. Build the review window into the release plan, and stop treating a same-day fix as possible.
• Use staged rollout. Release to a small percentage first, watch crash rates, then widen. This is the closest thing mobile has to a rollback.
• Put risky changes behind feature flags. A flag you can turn off server side is worth more than a fast fix you cannot ship.
• Keep a forced update path and test it. One day you will need every client above a certain version. That is a bad day to discover the mechanism is broken.
• Check the listing, not just the app. Rejections often come from permissions, privacy disclosures and metadata rather than from code.

Tool categories, without picking a winner

• Device clouds. Real hardware on demand, for the matrix pass and for reproducing a bug on a device you do not own.
• Automation frameworks. Appium for cross-platform, Espresso for Android, XCUITest for iOS, plus newer options like Detox and Maestro. Pick what your engineers can maintain.
• Crash and performance monitoring. Not testing tools exactly, but the best source of truth about which devices and OS versions are actually failing. Feed that back into your matrix every quarter.
• A place for the record. Where the documented cases, their review state and their run history live, including which device each run happened on.

Tesbo is that last category. It holds the documented cases and the run history and it drafts cases from a specification for a human to approve. It does not provide device infrastructure and it does not execute your mobile automation. Your framework, your device cloud and your CI stay yours.

Documenting mobile cases so coverage stays auditable

Here is the mistake that ruins mobile suites: duplicating a case once per device. A team with 200 cases and 8 devices ends up with 1,600 rows, and when the login flow changes they have to edit it 8 times. Within two releases the copies have drifted and nobody trusts any of them.

The fix is a clean split. The case describes the behaviour and stays device-agnostic. The run carries the environment.

So a run record for a mobile case has to include:

• Device model and OS version.
• App build number, not just the version name.
• Network condition, if the case depends on one.
• Install state: fresh install, or upgraded from which version.

With those four fields, a coverage report becomes a real sentence. This case passed on six device and OS pairs against build 4.12.0. It has not been run on the oldest supported OS since June.

That is something an engineering manager or an auditor can actually use. It is the same requirement-to-case-to-run trail described in test case management as the record a release rests on. Deciding which of those numbers belongs in the release report is a separate question, covered in the QA metrics worth reporting.

Two more habits worth keeping. Treat a device-specific failure as a real result rather than a flake, because on mobile "it only fails on that one phone" is usually a genuine bug and not noise. And when a check is expensive to automate on real hardware, decide deliberately. Not everything should be automated, and a documented manual pass on two devices sometimes beats a fragile automated one on eight.

Where to start if none of this exists yet

You do not need the whole programme next sprint. In order of return:

1. Write the interrupt checklist above and run it manually on two devices. It finds bugs immediately.
2. Pull your analytics and write down the matrix. Eight combinations, on a page, agreed by the team.
3. Add device, OS and build fields to your run records so coverage becomes reportable.
4. Automate the highest value flows first, using the same risk scoring as what to automate first.
5. Test the upgrade path from an old version before every release, because that is the one nobody remembers.

The general framing of how these layers fit together sits in our complete guide to software testing, and the wider decision about tooling and ownership is in test automation strategy.