Mobile & Web Client Testing
A mobile client is not "a website on a small screen". It runs in an environment that constantly interferes with it — an incoming call cuts off a flow, the network flips from Wi-Fi to mobile, the OS kills the process to reclaim memory, and the sheer zoo of devices and OS versions stretches the test matrix into dozens of rows. Half of all mobile defects do not reproduce on a desktop at all.
This block gathers what a tester needs to know about the client side: what kinds of apps and platforms exist, where to run them — on a real device, an emulator, or a simulator — how the browser behaves (engine, DOM, DevTools), and how to inspect traffic and logs when something breaks. The traps here are stubborn — people confuse an emulator with a simulator, name a browser instead of an engine, forget Huawei has no Google services. The full map lives in the layers below.
Topic map
- Mobile app types — native, web, and hybrid (WebView) apps and what each changes in testing.
- iOS vs Android differences — a closed uniform platform against an open fragmented one, and the Huawei trap.
- Devices, emulators, and simulators — how they differ and which to pick for early coverage versus a final pass.
- What is mobile-specific — network, lifecycle, permissions, and battery — a mobile-only defect class.
- Interruption testing — call, push, screen lock, and the requirement to preserve state.
- Semantic versioning — how to read
MAJOR.MINOR.PATCHand judge an upgrade's risk. - Browser engines — Blink, WebKit, Gecko, and why cross-browser bugs cluster off Blink.
- The DOM for testers — the page's tree of objects, CSS/XPath selectors, and verifying the rendered structure.
- DevTools and sniffers — what the browser's DevTools see and how a traffic proxy goes beyond them.
- Proxying device traffic — how to intercept and tamper with a phone's HTTPS requests via a root certificate.
- Reading logs —
logcat, the Xcode console, Kibana, and crash reporters as the source of the real cause. - Diagnosing missing push — the order of checks when one of two identical devices gets no notifications.
Common traps
| Mistake | Consequence |
|---|---|
| Confusing a hybrid app with a pure web app | Wrong conclusions about hardware access and what to test |
| Swapping emulator and simulator | In an interview it instantly reveals you do not know the platforms |
| Thinking an emulator replaces a real device | Missed defects in sensors, performance, and the network |
| Naming a browser (Chrome) instead of an engine (Blink) | The cross-browser matrix is built by browsers, not by engines |
| Forgetting Huawei lacks Google services | FCM push and Google sign-in silently fail while the cause is hunted in the code |
| Thinking DevTools capture other apps' traffic | Native traffic needs a proxy, not the Network tab |
| Forgetting the trusted root certificate for HTTPS | The proxy sees only the encrypted stream and nothing useful |
| Treating the on-screen message as the full cause | The real error and stack trace stay unread in the logs |
Interview relevance
The mobile block is asked to find out whether you have worked with real devices or know the topic from articles. The questions are almost always practical — "two identical phones, one gets no push, what do you check" or "design a cross-browser test matrix". What counts is not reciting definitions but the order of actions and knowing the traps.
Typical checks:
- The difference between native, web, and hybrid apps and what it changes in testing.
- Emulator versus simulator and when only a real device will do.
- The defect class that exists only on mobile, and interruption testing.
- How to inspect a phone's traffic and where to find iOS, Android, and backend logs.
Common wrong answer: "mobile testing is the same thing, just a smaller screen". In reality mobile adds a whole layer of environment — interruptions, network transitions, the process lifecycle, fragmentation, and permissions — and it is exactly there that the bugs a desktop suite will never find collect.