Mobile Testing: A Practical Guide

What makes mobile testing different

A web application runs in browsers the team can list, over a network the team can mostly assume. A mobile app runs on hardware the team does not control, under an operating system that manages its life: the OS decides when the app is paused, when it is killed to free memory, when it may use the network in the background and which data it may read. The ISTQB Mobile Application Testing syllabus (CT-MAT) treats these as the specific challenges of mobile: device and platform diversity, connectivity, limited resources, and the ways people use a device they carry everywhere.

In ISO/IEC 25010 terms, mobile raises the weight of compatibility (co-existing with other apps and the OS), reliability under interruption, performance efficiency (battery, memory, data), interaction capability (small screens, touch, one-handed use) and security (a device that can be lost, shared or rooted). A mobile test strategy should say how each of these is covered, not only whether the features work.

• Context changes constantly — network, location, orientation, battery level, foreground or background.
• The OS owns the lifecycle — the app must restore the user’s state after being killed, not only after being paused.
• Users run old versions — unlike a website, you cannot force everyone onto the latest build, so the back end serves several app versions at once.
• Distribution is gated — releases go through store review and staged rollouts, so a production defect takes longer to fix than on the web.
• Input is different — touch, gestures, on-screen keyboards, voice input, and assistive technologies such as TalkBack and VoiceOver.

Native, cross-platform, hybrid, mobile web and PWA

The type of app decides which risks exist and which tools can reach the UI. Know which one you are testing — and, for a hybrid app, which screens are native and which are web — before you plan anything.

• Native apps — written for one platform with its own SDK (Kotlin or Java on Android, Swift or Objective-C on iOS). They have full access to device features, and the platform test frameworks (Espresso, XCUITest) work directly. Treat each platform as a separate product that shares requirements.
• Cross-platform apps — one codebase built for both platforms (for example with React Native or Flutter). Business logic is shared, but rendering, permissions, keyboards and platform integrations still differ, so each platform needs its own UI pass.
• Hybrid apps — a native shell that hosts web content in a WebView. Test the seam: navigation between native and web screens, session and cookie sharing, the back button, file upload and camera access from web content, and what the user sees when the web content fails to load.
• Mobile web — a website used in a mobile browser. Check responsive layout, touch targets, viewport and zoom, the on-screen keyboard covering fields, and differences between mobile browser engines. The user-agent strings in your analytics show which browsers real users bring; many browsers now reduce or freeze the OS version and device model in that string (Chrome on Android, for example), so take OS versions and device models from User-Agent Client Hints or your app analytics SDK.
• Progressive web apps (PWAs) — web apps with a web app manifest and a service worker, installable to the home screen and able to work offline. Test installability, offline behaviour, cache updates (does a new release replace the cached one?) and push notifications where the platform supports web push for installed web apps.

Try it: User-Agent Parser

Device fragmentation, OS versions and screens

Fragmentation is the number of distinct environments your app must work in. On Android it comes from many manufacturers, each with its own customised system layer, many OS versions in use at the same time, and a wide range of screen sizes, densities and hardware. On iOS the device range is narrower, but several iOS versions and screen sizes are live at once, plus iPads with split-screen multitasking. Foldables and tablets add screens that change size while the app is running.

OS version differences matter because platforms change behaviour between releases: the permission model, background execution limits, notification rules and privacy features. An app that was correct on last year’s OS can fail on this year’s without a single line of its own code changing. Read each new OS version’s behaviour-change notes and turn every item that touches your app into a test — and run your regression suite on the OS beta before it reaches users.

• Screen size and aspect ratio — small phones, tall phones, tablets, foldables folded and unfolded, split-screen and multi-window.
• Density — layouts use density-independent units (dp on Android, points on iOS); check images for blurriness and text for clipping at low and high densities.
• Cut-outs and system bars — content hidden under the status bar, a camera cut-out or the home indicator.
• Orientation — portrait, landscape and the rotation itself: does the screen keep its state and the user’s input? WCAG 2.2 success criterion 1.3.4 Orientation requires that content is not restricted to one orientation unless that orientation is essential.
• Responsive behaviour — for mobile web and PWAs, check breakpoints, the viewport, horizontal scrolling and zoom; for apps, check that layouts adapt rather than stretch.
• Manufacturer layers — aggressive battery optimisation, custom permission screens and modified system dialogs on some Android devices.

Device strategy: emulators, real devices and device farms

No team can test on every device, so the device strategy is a risk decision. It answers three questions: which environments matter (from data, not opinion), which kind of device each test needs, and how often each combination is exercised.

Android emulators and iOS simulators are fast, free and scriptable — ideal for development and CI. They do not reproduce everything: real performance and thermal behaviour, battery drain, camera and sensors, biometric hardware, cellular networks, manufacturer customisations and parts of the push-notification path. An iOS simulator is not an emulator at all: it runs an app built for the host computer, so it is even further from real device hardware. Real devices are needed before release for performance, battery, camera, Bluetooth, NFC, payments, biometrics and anything that touches the manufacturer layer. Cloud device farms rent real devices (and emulators) remotely for automated suites or manual sessions — breadth without buying and maintaining a lab.

Build the device matrix from your own analytics: list OS versions, device models, screen classes and, for mobile web, browsers by share of active users. Cover the devices that carry most of your traffic, the oldest OS version you still support, the newest OS version (and its beta), one small and one large screen, and any device family that has produced incidents. Then combine the remaining parameters — language, orientation, network, font size — with pairwise selection instead of the full cross-product.

Example device matrix (illustrative; build yours from your analytics)

Tier 1 — every release, real devices
  Android latest   · Samsung mid-range · 6.4"  · ar-SA · 4G     (largest share of sessions)
  iOS latest       · iPhone standard   · 6.1"  · ar-SA · Wi-Fi
  Android oldest supported · budget device, 3 GB RAM · en-IN · slow 3G

Tier 2 — every release, emulators/simulators or device farm
  Android latest   · Pixel · font scale 200% · RTL
  iOS latest − 1   · small-screen iPhone · largest Dynamic Type size
  iPadOS latest    · Split View · landscape

Tier 3 — before major releases, device farm
  long tail: remaining models above 1% of sessions, one foldable, one tablet

Combination rule
  language × orientation × network × font size → pairwise set, not the full product

Try it: Pairwise Testing Generator Try it: User-Agent Parser

What to test on mobile: the map of risks

Functional testing of features uses the same techniques as anywhere else; the guide on writing test cases covers them. What is specific to mobile is a set of risk areas every app should cover. Each has detailed scenarios in the companion guide on mobile app test scenarios; this is the map.

• Installation, update and uninstall — clean install, update from each supported older version with data migration, reinstall after uninstall, cleared app data, backup and restore.
• Permissions — the first request, denial, permanent denial, revocation in system settings while the app is running, and one-time grants.
• Interruptions — incoming calls, notifications, alarms, switching apps, locking the screen, low-battery warnings, and the OS killing the app in the background.
• Network — Wi-Fi to cellular and back, offline, airplane mode, slow and flaky connections, captive portals, and offline changes that must sync when the connection returns.
• Device and display — screen sizes, orientation, dark mode, font scaling, the on-screen keyboard, gestures, foldables and multi-window.
• Resources — battery drain, CPU, memory (leaks, low-memory kills), storage (full disk, growing caches) and data usage on cellular.
• Push notifications — delivery in foreground, background and killed states, tap-through to the right screen, and behaviour when notifications are disabled.
• Accessibility, localization, security and store compliance — covered below and in their own guides.

Typical mobile defects (illustrative bug titles)

- Address form loses entered data after rotating the device (Android)
- App crashes on resume after camera permission is revoked in Settings (iOS)
- Order submitted twice when the network drops during "Place order" and the user retries
- Update from 3.8 to 4.0 signs every user out (stored session not migrated)
- Tapping an order notification opens the home screen instead of the order
- "Pay" button hidden behind the keyboard on small screens
- Checkout total truncated at the largest system font size
- Offline edits silently overwritten after reconnecting

Try it: Test Scenario Generator Try it: State Transition Generator

The mobile back end: APIs, versions and error handling

Many mobile defects that reach users are not in the UI but in how the app talks to its back end. The API is the part you can test fastest and most precisely: the same requests the app sends can be sent from an API client, and conditions that are hard to create on a device — a 503, a timeout, an expired token, a malformed body — can be produced on purpose.

Two mobile-specific concerns deserve their own tests. The first is version skew: users update late, so the back end must keep serving every app version you still support, and each API change needs a check against the oldest supported client. The second is the hostile network: requests are retried, duplicated and cut off halfway. Order and payment endpoints should be idempotent, and the app must show a clear state when the outcome of a request is unknown.

• Call each endpoint the app uses with valid, invalid and missing fields, and validate responses against the schema.
• Make the app face 401, 403, 404, 409, 429, 500 and 503 responses and slow responses; check the message and the recovery on screen.
• Let an access token expire while the app is in the background, then resume it: the app should refresh silently or ask the user to sign in, never crash or loop.
• Check payload sizes: large responses cost time and data on cellular networks.
• Before every back-end release, run the oldest supported app version against it.

Try it: REST API Tester Try it: API Status Code Simulator Try it: Mock Error Response Generator Try it: Response Size Analyzer

Mobile accessibility

Mobile platforms have their own assistive technologies, and an app has to be tested with them: TalkBack on Android and VoiceOver on iOS (screen readers driven by gestures), switch access, magnification, and system text scaling (font size on Android, Dynamic Type on iOS). WCAG 2.2 applies to mobile content as well as to the web — success criteria such as 1.3.4 Orientation, 2.5.1 Pointer Gestures and 2.5.8 Target Size (Minimum) are especially relevant to touch interfaces — and Android’s and Apple’s own accessibility guidance adds concrete expectations.

The accessibility testing guide covers the method in depth, including screen reader testing and visual accessibility. On mobile, start with these checks:

• Every interactive element has a meaningful spoken label, role and state; icon-only buttons are the usual failure.
• The TalkBack or VoiceOver swipe order follows the visual and logical order, including in right-to-left layouts.
• Text scales with the system setting without clipping, overlapping or truncated buttons; test at the largest sizes.
• Touch targets are large enough and spaced apart: Apple’s Human Interface Guidelines give 44×44 points as the default control size on iOS (28×28 points as the minimum), and Android recommends at least 48×48 dp.
• Custom gestures have a simple alternative such as a button, and no function depends only on shaking or tilting the device.
• Contrast holds in both light and dark mode.

Mobile security: MASVS and MASTG at a glance

The OWASP Mobile Application Security Verification Standard (MASVS) defines what a secure mobile app must do, and the Mobile Application Security Testing Guide (MASTG) describes how to verify it. MASVS groups its controls into areas: storage, cryptography, authentication, network communication, platform interaction, code quality, resilience against reverse engineering, and privacy. A functional QA team does not replace a mobile security assessment, but it can check the basics on every release and recognise when to bring in a specialist.

• Storage — no passwords, tokens or personal data in plain text in app files, preferences, logs or cached screenshots; secrets belong in the platform Keystore or Keychain. Check what stays on the device after logout.
• Network — all traffic over TLS, no fallback to plain HTTP, and certificate errors rejected rather than ignored.
• Authentication and session — tokens expire, and logout ends the session on the server, not only on the device; biometric unlock is tied to a valid server session.
• Platform interaction — deep links and components exposed to other apps validate their input; sensitive screens are hidden in the app-switcher preview where the risk requires it.
• Privacy — permissions requested only when needed and explained in context; the data collected matches the store privacy disclosures.

Platform quality guidelines and store readiness

Both platforms publish what they consider a quality app, and those documents make good checklists. Google’s Core app quality guidelines for Android set baseline criteria for visual experience, functionality, performance and stability, and privacy and security, together with the tests used to check them. Apple’s Human Interface Guidelines describe the expected behaviour of iOS interfaces — navigation, controls, layout, accessibility — and the App Store Review Guidelines describe what an app must meet to be accepted.

Use them as oracles for questions a requirement rarely answers: should the back gesture close this sheet? What should the user see when they return after hours? Is the permission requested in context? A deviation is not automatically a defect, but it should be a decision, not an accident.

• Back navigation — the Android back button or gesture and the iOS swipe-back gesture behave predictably on every screen.
• State restoration — the app returns to where the user was after being backgrounded or killed.
• Stability — no crashes and no "App not responding" (ANR) dialogs in the core flows.
• Start-up — cold start to a usable screen is acceptable on the lowest-end device you support.
• Store listing — screenshots, privacy disclosures and permission purpose texts match the app.

Automation, CI and release gates

Mobile automation follows the same pyramid as any product (see manual vs automated testing): many fast unit tests, a solid layer of API tests against the back end, and a smaller set of UI tests for the critical journeys. The UI layer uses the platform frameworks — Espresso for Android, XCUITest for iOS — or Appium, which drives both platforms through the WebDriver protocol. Stable UI tests depend on accessibility identifiers as locators, on the framework’s synchronisation instead of fixed sleeps, and on a controlled device state. The companion guide on mobile test automation compares the frameworks and lists the sources of flakiness.

In CI, run unit tests and emulator or simulator smoke tests on every change, and a wider suite on real devices in a device farm nightly or before release; keep the video, screenshots and device logs of every failure. Because a mobile release cannot be rolled back instantly, the last line of testing happens around the store: internal and beta distribution first (TestFlight on iOS, testing tracks on Google Play), then a staged or phased rollout that reaches a small share of users before everyone, with crash, ANR and API error rates watched at each step. A remote switch that can disable a broken feature is often the fastest fix available.

• Gate — no new crash cluster in the beta build during the agreed soak period.
• Gate — the oldest supported app version still passes its API smoke checks against the new back end.
• Rollout — pause if the crash-free rate or the success rate of a key flow drops below the agreed threshold.

Frequently asked questions

References

• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019ISTQB's specialist syllabus on mobile testing: app types, device and platform challenges, test types and tools.
• Core app quality guidelinesAndroid Developers (Google)Google's baseline quality criteria for Android apps — visual experience, functionality, performance, privacy and security — with the tests used to check them.
• Test apps on AndroidAndroid Developers (Google)Android's official testing guidance: test types and scopes, local vs instrumented tests, and testing best practices.
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP FoundationOWASP's security requirements for mobile apps, grouped into control areas such as storage, cryptography, authentication, network and platform interaction.
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP FoundationThe testing manual that goes with MASVS: techniques and test cases for verifying mobile app security.
• Accessibility — Human Interface GuidelinesAppleApple's accessibility design guidance for iOS and other platforms: VoiceOver, Dynamic Type, contrast, touch targets and motion.
• Appium DocumentationAppium (OpenJS Foundation)Official documentation for automating native, hybrid and mobile-web apps on iOS and Android.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).