Mobile App Testing Explained: A Complete Guide | Sauce Labs

A bug that appears only on a specific phone running a specific operating system version, connected to a specific network, is the kind of defect that ships to production undetected. The app runs on hardware you do not control, under conditions you cannot predict. The only real defense is testing that accounts for that before the build reaches the store.

‍

This guide covers what mobile app testing is, the six types of testing every mobile application needs, the process step by step, a checklist before every release, and the tools and frameworks that make it run.

What is mobile app testing?

Mobile app testing is the process of checking that a mobile application works correctly on real devices and operating system versions, covering function, performance, security, usability, and behavior under real-world conditions such as poor networks and interruptions.

‍

The scope includes native apps built for a single platform, hybrid apps that wrap a web view inside a native shell, and mobile web apps accessed through a browser. All three ship to the same fragmented device market and all three need to be tested against it.

‍

What makes mobile app testing harder than web testing comes down to variables outside the code. Device fragmentation spreads across hundreds of screen sizes and chipsets — and that's before manufacturer software layers get involved. Operating system versions follow different update timelines on Android and iOS devices, with Android carrying a longer tail of older versions still in active use. Conditions like low battery and limited device storage affect behavior in ways desktop browsers never encounter, and incoming calls are their own category entirely.

‍

Mobile app testing is not the responsibility of a single QA team. Developers run unit tests before merge. Automation engineers maintain regression suites. Manual testers handle exploratory sessions and usability reviews. The testing process spans all of these roles.

‍

One common mistake: treating mobile testing as running a web test suite at a smaller screen size. The inputs, the interruptions, and the deployment model are different enough that mobile application testing requires its own strategy.

How is mobile app testing different from web testing?

Web testing varies the browser, while mobile app testing varies the hardware, the operating system version, the network, and the device state, which means the same build can pass on one phone and fail on another with no code change between them.

‍

Screen sizes on mobile devices range from compact phones under six inches to foldables that change aspect ratio mid-session. Pixel densities vary enough that a tap target that works on one device overlaps adjacent elements on another. Safe areas for notches and camera cutouts differ across manufacturers.

‍

Operating system version spread is the second variable. On iOS, adoption of the latest version is typically high within months of release. On Android devices, a team supporting the last four major versions may be covering five or more years of releases, each with different API behavior and permission models.

‍

Device state introduces failures that have no web equivalent. Low battery triggers throttling on some operating systems. Low device storage causes write failures that surface as crashes. Background restrictions vary by manufacturer, and an app that runs fine on stock Android may be killed aggressively on a device with a custom power management layer.

‍

Interruptions matter on mobile in ways they do not on the web. An incoming call during a payment flow, a notification that steals focus, an app switch that triggers a backgrounding cycle, a screen rotation mid-transaction: these are normal user behavior, and if the app does not recover, the defect ships.

‍

Store review requirements impose a gate that web apps do not face. Permissions must be justified, privacy labels must match data collection, accessibility standards must be met, and content ratings have to reflect what's actually in the app before submission.

Types of mobile app testing

Six types of testing cover the surface area of a mobile application. Each catches a different class of defect, and each has different requirements for where it runs.

Functional testing

Functional testing confirms that the app does what it is supposed to do: core user flows, form submissions, movement between screens, deep link handling, and push notification behavior. Installation testing covers the first launch, an upgrade over an existing version, and uninstall cleanup. Permissions testing verifies behavior on first run and when the user denies a permission the app expects.

‍

Most functional test cases run fine on virtual devices. The exception is anything that touches hardware directly (camera, biometrics, NFC, Bluetooth), which requires real device testing.

Compatibility testing and device fragmentation

Compatibility testing verifies that the app behaves consistently across the device and operating system matrix your users run in production. That matrix is drawn from your own analytics, not from global market share tables.

‍

The variables include screen sizes, aspect ratios, DPI buckets, and foldable form factors. On Android, the manufacturer layer (Samsung One UI, Xiaomi MIUI, OnePlus OxygenOS, Huawei EMUI) is where a surprising share of compatibility defects live. A feature that works on stock Android may break on a manufacturer build that modifies background process handling or notification delivery.

Performance testing

Performance testing tracks startup time, memory usage, battery usage, and app size as measurable KPIs. Test on mid-range hardware, not on flagship devices. A flagship phone masks performance problems that surface immediately on the devices most of your users carry.

‍

Performance testing requires real devices. Virtual devices do not reproduce thermal throttling, real battery drain or the memory pressure that occurs when other apps compete for resources on a constrained device.

Security testing

Security testing checks how the app handles sensitive data at rest and in transit. Credentials, tokens, personal data, and anything else sensitive should not be written to unencrypted files or shared preferences. Secure authentication flows, session management, certificate pinning, and properly configured transport encryption protect data in transit.

‍

Binary scanning catches hardcoded secrets, API keys, debug flags, and leftover logging statements that should not ship in a release build. The OWASP Mobile Application Security Verification Standard (MASVS) is the reference checklist for rigorous security testing on mobile.

Usability and accessibility testing

Usability testing evaluates whether the app is easy to use under real conditions: one-handed use and tap target sizes that account for imprecise touch input, plus gesture handling that does not conflict with the system’s own gestures.

‍

Accessibility testing covers screen reader support on both iOS (VoiceOver) and Android (TalkBack), color contrast ratios, dynamic type sizes, and focus order for assistive technology. Onboarding friction should be measured with real users rather than assumed by the team that built it.

‍

This is the type of testing that automation is worst at replacing. Automated tests can verify that accessibility labels exist, but they cannot tell you whether the experience makes sense to a user navigating by voice. Manual effort is the primary method here.

Network and interruption testing

Network and interruption testing covers conditions unique to mobile. Behavior on 3G, throttled connections, packet loss, and full offline mode should all be verified. Recovery when connectivity returns mid-request is a frequent source of defects, particularly for apps that queue writes locally.

‍

Interruption scenarios include incoming calls, alarms, system notifications, and the low-battery warning. App switching, backgrounding, and restoration from a killed state are normal user behavior that the app must handle without data loss. These test cases run on real devices, since virtual devices do not generate real interruptions.

Native, hybrid, and mobile web apps: what changes

The type of app changes the weight of each testing type. Native apps have full access to device features and use platform-specific testing frameworks (Espresso on Android, XCUITest on iOS). They are the most sensitive to device and operating system variation.

‍

Hybrid apps share a single codebase but render through a web view whose behavior differs per platform and per web view version. Performance testing matters more here because the abstraction layer introduces overhead that varies by device.

‍

Mobile web apps are closer to browser testing. The device conditions above still apply (network, interruptions, screen sizes, device state), but installation testing and push notification handling do not apply, nor does store submission.

The mobile app testing process, step by step

A repeatable testing process turns the types above into a sequence your team can run on every release.

Define scope and build the device matrix

Pull device, operating system, region, and app-version data from your own analytics. Set coverage tiers: which devices get full regression runs, which get smoke tests, and which fall outside support. Output: a named device list with operating system versions that the release is tested against.

Write test cases and tag them by risk

Write test cases with a single assertion each so a failure names its cause without investigation. Tag each case by risk: high-risk cases run on every build, lower-risk cases run per release. Output: a test case set mapped to requirements, with measurable test coverage per feature.

Choose what to automate and what stays manual

Automate regression testing, smoke tests, sanity checks, and any data-driven test case that runs repeatedly. Keep exploratory testing and usability sessions manual. Same with first-run experience evaluation since that's a judgment call no script can make. Output: an automation backlog ordered by execution frequency rather than by ease of automation.

Execute across real and virtual devices

Run virtual devices for early functional feedback on every commit. Switch to real device testing for performance validation, hardware-dependent features, interruption scenarios, and pre-release regression. Capture video and logs per run so a failure can be diagnosed without reproduction. Output: a run history that can be compared build over build.

Triage, report and measure

Review failed tests within one business day. Quarantine flaky tests rather than retrying them, since a flaky test that passes on retry masks a real defect. Report defects with the device model, operating system version, session log, and reproduction steps attached. Output: device and operating system coverage percentage, flaky test rate, and a release risk assessment.

Manual testing vs. automation testing on mobile

Both manual testing and automation testing are required on mobile. The question is where each one fits.

‍

Automation testing handles regression across a device matrix and repeated flows through forms and checkout — anything scripted enough to run in parallel across multiple devices in CI without a human watching it. It gives speed and coverage on the cases that do not change between releases.

‍

Manual testing is still required for usability evaluation, first impressions of new features, unscripted device behavior, and store review readiness. A human tester catches the problems that no assertion was written for: layout issues on an unexpected screen size, a gesture conflict with the OS, and the kind of interruption-recovery bug that only shows up in someone's hands.

‍

The maintenance cost of mobile automation is higher than web automation. Locator strategies drift across operating system versions, especially on Android where manufacturer UI layers change element hierarchies. A working split for most teams: automated regression on every build, a manual exploratory session per release.

How to build a device matrix from your analytics

Device fragmentation becomes manageable when you rank devices by your own data rather than by global popularity. The device matrix turns an unbounded problem into a defined list with clear testing depth per tier.
‍

Cover operating system versions separately from device models since a device on an older OS version behaves differently from the same device on the latest update. Refresh the matrix quarterly and at every major operating system release. When a device or version falls below your support threshold, move it to tier four and document the change in your release notes.

Mobile app testing checklist before release

Before every release

• Unit tests and API tests pass on the release branch
• Full regression run complete across tier one and tier two devices
• Performance KPIs (startup time, memory, battery usage, app size) validated on a mid-range device, not a flagship
• Fresh install, upgrade over the previous version, and offline launch all verified
• Interruption scenarios (incoming call, notification, app switch, low battery) covered on at least one device per platform
• Crash reporting and analytics confirmed as reporting from the release build

Before a store submission

• Security checks passed against the MASVS checklist
• Permissions and their usage descriptions match what the app requests
• Store listing assets (screenshots, previews) validated at the required screen sizes
• Accessibility walkthrough complete on both iOS and Android
• Rollback plan agreed, with a named owner for the release decision

Mobile app testing tools and frameworks

Appium

Appium is the most widely used cross-platform automation testing tool for mobile. It supports native apps, hybrid apps and mobile web apps across Android and iOS devices using a single test suite. The trade-off is setup complexity: configuring Appium with the right drivers, capabilities, device connections, and platform quirks takes more effort than a platform-native framework. Appium fits best when the team tests both platforms and wants to share test code across them. For more on alternatives, see this overview of test automation frameworks.

Espresso and XCUITest

Espresso (Android) and XCUITest (iOS) are the platform-native testing frameworks maintained by Google and Apple. Tests run faster and produce more stable results than cross-platform alternatives, because they interact with platform APIs directly rather than through a bridge. The cost is maintaining two separate test suites. These frameworks fit best when platform teams own their own tests.

Device clouds and device labs

An in-house device lab gives direct access to a handful of critical models. The maintenance cost is real: devices need charging, OS updates, replacement on failure, and physical management. A device cloud provides breadth, parallel test execution, and access to devices nobody wants to purchase and maintain individually.

‍

When comparing providers, evaluate real device count, parallel session limits, maximum session length, and the quality of log and video capture. For a detailed comparison of the two models, see device farm vs. device cloud.

Test lab and supporting services

Firebase Test Lab provides automated testing on Google-hosted Android devices, including a robo test that crawls the app to find crashes without written test cases. AWS Device Farm offers device breadth for teams inside an existing AWS setup. Both are useful for broad crash-level coverage across the Android long tail.

‍

Visual testing tools catch UI regressions that functional assertions miss: a button shifted by two pixels, a truncated label, an overlapping element on a specific screen size, or a font that renders half a pixel off on one display panel. Crash and performance monitoring services (Sauce Error Reporting, Firebase Crashlytics, Sentry, Datadog) cover the production half of the testing job.

Which tool is best for mobile app testing?

The answer depends on the team, the platform mix and the budget.

‍

For a single-platform team with in-house mobile developers, the native framework is the best starting point. Espresso on Android or XCUITest on iOS gives the fastest, most stable automation with the lowest maintenance overhead.

‍

For a team testing both platforms with a shared QA group, Appium paired with a device cloud provides cross-platform coverage without duplicating the entire test suite.

‍

For teams with no budget for physical devices, a device cloud is the practical choice over an in-house device lab. Device refresh, charging infrastructure and physical management cost more over time than cloud access for most team sizes.

‍

For Android-heavy consumer apps, combine automated test coverage with a crash-level sweep across the long tail of devices your automation does not cover individually.

‍

The honest answer: The testing framework matters less than where the tests run. Most mobile defects are device-specific, meaning they appear on a particular combination of hardware and operating system version. Choosing the right device matrix and running tests on real devices for the cases that matter is more impactful than choosing between Appium and Espresso.

Real device cloud vs. emulators and simulators

Emulators and simulators are good for fast feedback. They start in seconds, cost nothing beyond compute, and handle the majority of functional test cases accurately. For early checks on every commit, virtual devices are the efficient choice.

‍

What they cannot reproduce is the list that matters for release confidence: hardware sensor behavior, real battery drain, thermal throttling under sustained load, real network conditions, and the manufacturer software layers that modify Android behavior per device. A test that passes on an emulator yet fails on a real device is a coverage gap that reaches users.

‍

A workable split: virtual devices on every commit for fast functional feedback, real devices on merge to the main branch and before every release for tests that require hardware fidelity. Buying and maintaining even 20 physical devices in house (with charging, updates, replacement, and physical space) costs more annually than access to a device cloud that offers hundreds.

‍

Most teams settle on virtual devices for early runs and a real device cloud for the pre-release regression. The deciding factor is usually parallel capacity (how many real devices can run simultaneously) rather than total device count.

Where Sauce Labs fits in mobile app testing

Sauce Labs provides a mobile app testing platform that covers two parts of the process described above: the real device cloud for pre-release regression and hardware-dependent testing, plus emulators and simulators for the early functional runs on every commit.

‍

The real device cloud supports parallel execution across the device matrix, so that expanding device coverage does not add time to the release cycle. Each session captures video, device logs, network activity, and performance data, diagnosing device-specific failures without reproduction.

‍

Unit tests run in the build pipeline. Usability sessions require human observation. Store submission checks are manual by nature. Where Sauce Labs fits is the device-dependent middle: regression runs, compatibility checks, performance validation, and interruption testing that require real hardware at scale.

‍

BrowserStack App Automate and AWS Device Farm are alternatives in the device cloud space. BrowserStack offers a large real device inventory with a focus on manual and automated app testing. AWS Device Farm fits teams that want device testing integrated into their existing AWS infrastructure. Evaluate each on real device count, parallel capacity, log quality, and CI integration.

Run your first real device test this week

• Day one: Pull the top 10 devices and operating system versions from your analytics and write the device matrix down. If analytics are not available, start with the tier one defaults for your market and refine after the first release.
• Day two: Run the existing smoke suite against three of those devices on a device cloud. Record every failure that did not appear when testing locally.
• Week one: Automate the five user flows that break most often and add them to the CI pipeline so they run on every build.
• Week two: Add interruption and network test cases (incoming call, offline launch, throttled connection). Measure device and operating system coverage against the matrix.
• Review point: If fewer than half the defects found are device-specific, spend the next cycle on test depth (more test cases on fewer devices) rather than device breadth (more devices with the same test cases). The matrix will tell you where to invest.

‍

Before you spend on a device lab, try Sauce Labs for free and run this week's plan against a real device cloud instead — you'll know within a day whether device breadth or test depth is your actual gap. Book a demo for help mapping your own device matrix first.

‍