Mobile Testing

Testing Android applications using UIAutomator2 as the underlying automation engine. Appium communicates with UIAutomator2 over ADB (Android Debug Bridge), enabling interaction with any visible element including system dialogs. Elements are located by resource-id, content-desc, or UiSelector queries.

An Android system dialog triggered when the main thread of an app is blocked for more than 5 seconds while handling a user input event, or more than 10 seconds for background processing. The OS determines that the app is unresponsive and presents the user with 'Application Not Responding' — options to wait or force-close. ANRs signal that expensive work (network calls, database queries, file I/O, complex computation) has been performed on the main thread instead of being offloaded to a background thread. Android Vitals (Google Play Console) tracks ANR rate as a core quality metric. Reproduce and diagnose ANRs using Android Studio's CPU Profiler, StrictMode (which detects main-thread IO in debug builds), or Perfetto traces. iOS does not use the term ANR but has an equivalent concept: main-thread hangs that trigger watchdog terminations.

An open-source mobile test automation framework that implements the W3C WebDriver protocol for native, hybrid, and mobile web apps on iOS and Android. Appium drives apps from the outside — no app source code required — using UIAutomator2 on Android and XCUITest on iOS as its underlying automation engines.

Logging in via fingerprint, face, or iris instead of a password — Touch ID / Face ID on iOS, BiometricPrompt on Android. The app delegates to the OS, which returns success/failure without exposing the biometric data. QA tests the fallbacks as much as the happy path: what happens on no-match, no enrolled biometric, hardware unavailable, or lockout after repeated failures.

The time from when a user taps an app icon to when the first interactive frame is visible, measured when the app process is not already in memory. A cold start is the worst-case launch scenario: the OS must create a new process, load the app binary from disk, initialise the runtime (JVM on Android, Swift/ObjC runtime on iOS), and render the first frame. Warm starts — where the process exists in memory but the activity was destroyed — are faster. Hot starts — where the activity is merely paused — are fastest. Google's Android Vitals targets 5 seconds as the threshold beyond which users abandon the launch; well-optimised apps aim for under 2 seconds. Testing cold start requires clearing the app from memory (via adb shell am force-stop or equivalent), then timing the launch with Perfetto, Xcode Instruments, or platform-native profiling tools.

A URL that opens a specific screen inside an app rather than its home screen — e.g. `myapp://orders/1042` or a universal `https://` link that the OS routes into the app. Deep links power notifications, share flows, and marketing campaigns, and they break quietly: a malformed link or unhandled path dumps the user on the wrong screen or a crash.

Two terms often used interchangeably but with an important technical distinction: Android uses emulators (which emulate the hardware and run the actual Android OS), while iOS uses simulators (which simulate the OS environment on macOS but do not emulate ARM hardware). The practical consequence is that iOS simulators cannot run compiled ARM binaries and do not expose hardware like Face ID or GPS the same way a real device does. Android emulators run closer to real device behaviour but are still slower than physical hardware and miss OEM-specific customisations. For test planning, both are suitable for functional and regression testing of happy paths. Only real devices expose reliable cellular network behaviour, hardware-specific rendering, and biometric prompts.

A mobile application that wraps a web view inside a native shell. The core logic and UI render in a WebView (similar to a browser), while the native shell provides access to device APIs like the camera and push notifications via a bridge (Cordova, Capacitor, or a similar runtime). React Native and Flutter are sometimes called hybrid but are more accurately cross-platform native — they compile to native components rather than rendering in a WebView. Hybrid apps introduce a dual test surface: the native shell behaves like a native app and needs Appium-style locators, while the embedded web content can use CSS selectors. Context switching between the two (via Appium's getContext / switchContext) is a common source of test flakiness.

Testing iOS applications using XCUITest as the underlying automation engine. Appium wraps XCUITest through WebDriverAgent — a signed XCTest agent installed on the target device or Simulator. iOS testing requires macOS and Xcode and uses XCUIElementType accessibility attributes and NSPredicate strings for element location.

The practice of verifying mobile applications — native, hybrid, and mobile web — across devices, OS versions, and screen sizes. Mobile testing encompasses functional testing, gesture interactions, permissions handling, context switching for hybrid apps, and OEM-specific behaviour that emulators may not replicate.

A mobile application built with platform-specific languages and SDKs — Swift or Objective-C for iOS, Kotlin or Java for Android. Native apps have full access to device hardware (camera, NFC, biometrics, GPS), run with the best performance characteristics, and follow each platform's UI conventions. For testers, native apps require platform-specific automation frameworks: XCUITest for iOS or Espresso for Android at the unit/integration layer, and Appium's UIAutomator2/XCUITest drivers at the end-to-end layer. Native apps are the gold standard for user experience but the most expensive to build and test across both platforms.

How an app behaves with no or intermittent network — queuing actions, serving cached data, and syncing when connectivity returns. Mobile networks drop constantly (tunnels, lifts, flaky wifi), so "works offline" isn't a feature so much as a requirement. The hard part QA targets is the transition: what happens to in-flight actions when the connection drops and returns.

The OS-level prompt asking a user to grant an app access to a protected resource — camera, location, contacts, notifications. Permission dialogs are system UI (not your app's), so they behave differently per OS and version, and the app must handle every outcome: granted, denied, "ask every time", and permanently-denied (where the only fix is Settings).

A message delivered from a server to a client device or browser without the client polling — using APNs (iOS), FCM (Android/web), or the Web Push API. Testing concerns include: notification delivery when the app is in the foreground vs. background vs. closed, correct payload content, deep-link routing when the user taps the notification, handling of denied or revoked permissions, and notification grouping or badge-count accuracy. Also test what happens when the device is offline and comes back online.

Executing mobile tests on physical hardware rather than emulators or simulators. Real devices expose OEM-customised operating system behaviour, hardware sensors (camera, NFC, biometrics), accurate memory constraints, and battery draw that emulators cannot replicate. Some bugs — particularly around network transitions, memory pressure, specific display resolutions, and vendor-modified system apps — only appear on real hardware. Cloud device farms (BrowserStack App Automate, Sauce Labs Real Device Cloud, AWS Device Farm) provide access to hundreds of device/OS combinations without requiring physical ownership or lab infrastructure. The pragmatic strategy for most teams: run functional suites on emulators in CI for speed, then run a targeted regression matrix on real devices before each release.