Mobile & Web Client Testing

WCAG is the standard — success criteria under four principles at levels A/AA/AAA. axe is an automated engine scanning the rendered DOM for violations like missing labels or low contrast. Lighthouse audits a page and scores accessibility. Automated tools catch only part; contrast, labels, and structure still need manual and assistive-tech checks.

A real device gives the most accurate results — true sensors, performance, and network — but is costly. An emulator (Android) models the hardware and OS; a simulator (iOS) only imitates the environment without true hardware emulation. Prefer emulators/simulators for early, cheap, wide coverage and real devices for final and regression passes.

A native app is built per platform with the platform SDK, has full device access, and the best performance. A web app runs in the browser and is platform-independent but limited in device access. A hybrid app is web code wrapped in a native shell (a WebView), trading some performance for one shared codebase.

DevTools (Network, Console, Elements, Application tabs) inspect the page the browser rendered and the browser's own requests and responses. A traffic-inspection proxy (a sniffer like Charles or Fiddler) sits between client and server and can intercept and modify any app's traffic — not just the browser's — with map local/remote, breakpoints, and throttling.

Interruption testing verifies an app behaves correctly when something interrupts it mid-use and then resumes. Scenarios: an incoming call or SMS, a push notification, an alarm, low battery, the app being backgrounded then reopened, network loss, and the screen locking. The app must preserve state and recover gracefully after each interruption.

iOS is a closed, uniform ecosystem with few device models and strict App Store guidelines. Android is open-source with huge fragmentation — many vendors, custom skins, OS versions, and form factors. A key trap: Huawei devices lack Google services, so push via FCM and Google sign-in fail there. Each platform also has its own languages, stores, and review rules.

Android: logcat (via adb logcat or Android Studio). iOS: the Xcode console or the macOS Console app. Backend: a centralized log system like Kibana/ELK or Grafana. Crashes go to Crashlytics or Firebase. Logs let a tester see the actual error, stack trace, and request flow behind a symptom, turning a vague "it failed" into a precise, reportable cause.

A responsive web app varies along the viewport: breakpoints, widths, orientation, browser zoom, and text scaling, via DevTools device emulation. A native app varies along the device: OS versions, densities, vendors, platform UI conventions, gestures, hardware, permissions, and store review. Responsive testing chases layout reflow in a browser; native chases device and OS fragmentation.

A browser engine is the component that parses HTML/CSS and renders the page. The three main ones are Blink (Chromium → Chrome, Edge, Opera), WebKit (Safari), and Gecko (Firefox). The key tester insight: Chrome and Edge share an engine, but Safari and Firefox do not, so cross-browser bugs cluster on the non-Blink engines.

The DOM (Document Object Model) is the tree of objects the browser builds from the page's HTML, representing every element and its state. Testers use it to locate elements with selectors (CSS/XPath) for manual checks and automation, to inspect or modify an element's current state, and to verify that the rendered structure matches what is expected.

Route the device through a proxy tool — Charles, Fiddler, Proxyman, or mitmproxy — and install its trusted root certificate so it can read HTTPS. Then you can inspect requests and responses, modify them, map local/remote, rewrite values, throttle the network, and fault-inject (for example force a 500 on one endpoint) to test how the app handles errors.

With the backend and network ruled out, the cause is device- or account-side. Check: notification permission disabled, system or app-level notifications off, battery saver / Doze killing the background process, a stale or missing push token, no Google services (Huawei → FCM token never issued), a different logged-in account, Do-Not-Disturb mode, or an OS-version push difference.

Mobile adds concerns absent on desktop: network transitions (Wi-Fi↔mobile, loss), interruptions (calls, SMS, push), huge device and screen fragmentation, app lifecycle (background/foreground, being killed), permissions, and battery. Mobile-only defects cluster around these — state lost on backgrounding, broken behavior on a flaky connection, or layout breaking on an unusual screen.

Cover localization end to end: translations and truncation, RTL layouts, locale-specific date/number/currency formats, and the device-locale vs in-app-locale split. Verify each region's payment acquirer and legal/regulatory rules, and build a device matrix weighted by market share. Scope regression by risk: retest shared core everywhere, but locale- and payment-specific flows only in affected regions, with a time-box plus a risk buffer.

Target 60 fps, a ~16.6 ms per-frame budget; frames over that are dropped and read as jank. Reproduce on low-end and older devices, not just a flagship, and measure with a profiler — dropped frames, CPU/GPU load, memory, and startup time. Report with device, OS, repro steps, the metric trace, and a video, so a developer can act on a concrete, measured regression rather than a vague feel.

Test with real assistive tech on each platform — VoiceOver on iOS, TalkBack on Android, NVDA on desktop web — not automated scans alone. Verify each client-side route change is announced and focus moves to the new view, not the stale element. Confirm dynamically loaded content is exposed via ARIA live regions and correct roles so it is read aloud. Automated tools check static markup, so they miss these dynamic-update and focus failures.

It is semantic versioning, MAJOR.MINOR.PATCH. MAJOR (4) bumps on breaking, incompatible changes; MINOR (21) on new backward-compatible features; PATCH (3) on backward-compatible bug fixes. The scheme lets a tester or user infer the risk of an upgrade from the numbers alone.

Choose devices by evidence: market share, your usage analytics, crash-report hotspots, and business-critical segments. Balance real devices for high-value cases against emulators and a cloud farm for breadth. Tier it: a smoke set per build, a wider risk-weighted set before release. Refresh as new models, OS versions, and vendor quirks appear, justifying each uncovered device by low share and risk.

Reproduce it with a proxy or link conditioner injecting latency, packet loss, and Wi-Fi/cellular flapping — not just airplane mode. Verify offline queueing and sync on reconnect, retry with backoff, and idempotent retried writes so a resent order is not duplicated. Check conflict resolution, partial-data rendering, timeouts, and clear feedback. The focus is data integrity under uncertainty, not a clean drop-and-restore.