Skip to content

Mobile QA, the principles

This course aims you at web automation with JavaScript, and that is where your time should go. But mobile comes up in interviews and in real teams, and the good news is that most of what you already know transfers. This page is awareness, not a second career: enough to test a mobile web app sensibly and to talk about native testing without bluffing.

Why

The testing mindset does not change on mobile. You still make risk visible, design cases with the same techniques, and write reproducible bug reports. What changes is the list of things that can go wrong, and that list is longer on a device someone carries around all day.

Know what kind of app you are testing

The word "app" hides four quite different things, and the difference decides your approach. A native app is built for one platform (Swift for iOS, Kotlin for Android) and installed from a store. A hybrid app wraps web content in a native shell. A mobile web app is just a website viewed on a phone. And a progressive web app is a website that behaves more like an installed app. The closer to plain web, the more your existing skills apply directly.

The concerns that web does not have

Testing mobile means holding a longer list of ways the world interferes. Device fragmentation comes first: countless screen sizes, resolutions, and operating system versions, and you cannot test them all. You choose a representative set by risk, the popular devices and the OS versions your users actually run, which is risk based testing wearing a different hat.

Then there is everything a phone does that a desktop does not. Interruptions: a call arrives, a notification drops, the user switches apps and comes back, the battery dies. Your app should survive all of it and resume where it was. Network: mobile connections go offline, crawl, or switch from wifi to cellular mid-action, so an app that assumes a fast, stable connection will embarrass itself on a train. Gestures and input: tap, swipe, pinch, long-press, and a keyboard that slides up and covers the field you were typing into. Orientation: rotating the device should not lose your data. Permissions: camera, location, and notifications can be granted or denied, and both paths need testing.

Tip

A quick way to find real mobile bugs: turn the network off mid-task, rotate the screen, and background the app then return. Those three moves surface more issues than an hour of tapping through the happy path.

Real devices, emulators, and simulators

An emulator (Android) or simulator (iOS) runs a fake device on your computer. They are fast and free, and fine for early checks of layout and logic. They are not the truth, though: real performance, real touch behaviour, real sensors, and real network conditions only show up on real hardware. Teams usually do both, and use a device cloud like BrowserStack (opens in a new tab) or Sauce Labs (opens in a new tab) to reach the devices they do not own.

The tools, for awareness

You do not need these yet, but you should recognise the names. For native automation, Appium (opens in a new tab) drives both iOS and Android and, helpfully, has JavaScript bindings and a WebDriver-style approach, which makes it the shortest bridge from what this course teaches to native testing. Platform-specific tools exist too: Espresso (opens in a new tab) for Android and XCUITest (opens in a new tab) for iOS. For mobile web, you already have the best starting point: your browser.

Tip

Try it now, no install required. Open SauceDemo (opens in a new tab) in Chrome, open DevTools, and switch on the device toolbar to emulate a phone. Resize across a few device presets and watch what the layout does. That is mobile web testing, and it uses skills you already have.

Accessibility counts double here

Phones are how a lot of people with disabilities use the internet, so mobile accessibility is not optional. The screen readers to know are VoiceOver on iOS and TalkBack on Android. Dynamic text sizing, sufficient contrast, and touch targets large enough to hit without a surgeon's aim all belong on your list.

When you are ready to go deeper, the same instincts from week two apply straight to mobile: pick your risks, design your cases, and write reports a developer can reproduce. The device is new; the discipline is not.