Introduction to Mobile Application Testing
This domain frames why mobile testing differs from desktop and web work: the app ships onto hardware, OS versions, networks and store pipelines that the test team does not own. The exam checks that you can name the mobile application types, tie business models to test priorities, and reason about fragmentation as risk rather than as a slogan.
Application types
- Native - compiled separately per platform, full device-API access, distributed through app stores. Needs per-platform suites covering camera, sensors, push.
- Mobile web - runs in the device browser, no installation. Risk shifts to browser engine, responsive layout, latency.
- Hybrid - native shell plus WebView content. Test both layers and the boundary, and switch automation context between them.
Business model sets test priority
- In-app purchase / freemium: payment flow, receipt validation, restore purchases.
- Subscription: trial expiry, renewal, entitlement across devices.
- Ad-supported: ad behaviour during interruptions and offline.
- Paid: licence checks, refunds.
Fragmentation as risk
Device models, OS versions, vendor skins, screen densities and chipsets multiply the configuration space. You cannot test all of it, so select by analytics (devices and OS versions actually in use), feature usage and business criticality - risk-based portability testing.
Worked example
A hybrid retail app fails at checkout on one Android manufacturer only. The native shell passes, so the defect sits in WebView content rendered by that vendor's older WebView component. Recording the WebView engine version in the compatibility matrix and adding the oldest supported WebView to the test set converts a surprise into a managed configuration risk.
Traps that cost marks
Emulator passes treated as device coverage; testing only a clean install and never the upgrade path with existing user data; calling a hybrid app "mobile web" and skipping native-layer tests; ignoring store review, staged rollout and forced-update behaviour.