Mobile Testing

Half of Fernway's bookings come from the mobile app — and mobile is not "the website, smaller." Phones lose signal in tunnels, get killed by the operating system to save battery, interrupt checkout with incoming calls, and ship in thousands of hardware variants. Mobile testing is functional testing plus a hostile physical world — everything you already know, wrapped in conditions a desktop browser never faces. This page maps that hostile world so you can converse in it and test the app that carries half the revenue.

Food trucks make the shift concrete. Same cooking as a restaurant — but now the kitchen moves, the power flickers, weather interferes, and the health inspector must approve before you can serve anything, including corrections. Mobile is the food-truck version of testing.

What's Genuinely Different

Four families of condition the web never taught you — each a new region of your Chapter 4.6 catalog. Interruptions: a phone call, a notification, or the user switching apps mid-payment — what does checkout return to? Connectivity: offline, flaky signal, the wifi-to-cellular handoff mid-request (the booking submitted on wifi that completes on cellular — did it survive, or double-submit?). Device states: low battery (does the OS throttle the app?), low storage, rotation portrait-to-landscape mid-form. Permissions: location denied — does search still work, or crash? Camera denied, notifications denied. Each family is a test-case cluster with no desktop equivalent, and together they're why mobile has its own specialty.

The Fragmentation Problem

Thousands of device-and-OS-version combinations exist — different screen sizes, different Android skins, different iOS versions still in the wild. You cannot own them all, and testing all of them is Chapter 4's combination explosion, now load-bearing for real: pairwise (Topic 20) is exactly the professional answer — cover the important pairs of device × OS version, not every combination. And where you don't own the hardware, device farms — cloud services offering hundreds of real phones you rent by the minute (a category to know, one line) — fill the gap. Fragmentation is why "test on my phone" is never a mobile test strategy.

Real Devices vs Emulators

An emulator (Android) or simulator (iOS) is software pretending to be a phone on your computer — fast, free, and fine for most functional work: does the button work, does the form validate. But it can't fully reproduce real touch, real performance, the actual camera, or the genuinely weird hardware-specific bugs. So the honest rule: emulators for breadth, real devices for confidence. Run wide coverage on emulators (cheap, parallel), then verify the risky flows — payment, the interruption cases — on real hardware before release. Both, deliberately; neither alone.

App Lifecycles and the Store Gate

Two more mobile-specific realities. First, app lifecycles — Chapter 4's state diagrams meet the operating system: an app gets backgrounded (user switches away), suspended, sometimes killed to reclaim memory. Backgrounded during payment: what does the user return to — the confirmed booking, a blank screen, a re-submitted charge? Plus updates: does version 3.1 install cleanly over 3.0 with a booking in progress? Second — and this one changes the severity math — the store gate: mobile releases pass through Apple's and Google's review before reaching users. That means no instant hotfixes — a mobile bug fix waits for store approval (hours to days), so a bug that would be a same-day web patch is a multi-day mobile incident. Mobile bugs cost more because mobile fixes ship slower; risk-based planning (Chapter 7) has to weight mobile findings accordingly.

FW-425: the Interrupted Payment

The charter: book a stay on the app while hostile — airplane mode toggled at payment, a phone call mid-checkout, rotate at every screen, deny every permission. The call test finds it: a phone call arrives during payment, the user answers, then returns to the app — and the payment screen re-submits. Double charge. FW-425 — and you recognize it instantly: it's FW-360's mobile cousin (the double-click double-charge), the same idempotency failure wearing an interruption costume instead of a double-click one. The interruption catalog joins your Chapter 4.6 list permanently: every money-moving mobile flow gets the call-interruption test. And the tooling handoff, honest as always: automating mobile deeply uses Appium (Topic 40's mobile driver) and the platforms' own frameworks; deep mobile automation is beyond this book, named so you recognize it. Next chapter: the newest frontier — AI in testing, and testing AI.