// Interview Prep/Mock Interviews/Mobile QA mock interview

📱 Mobile QA mock interview

Set a timer, work through each round out loud, then score your answers against the rubric. No one is listening — the goal is honest self-assessment, not a perfect performance.

Mid⏱ 45 min·Mobile QA, Mobile Automation QA

// ROUND STRUCTURE

  1. 1
    Warm-up— 5 min

    Background, platforms tested (iOS/Android), and your current mobile test stack.

  2. 2
    Mobile fundamentals— 12 min

    Device fragmentation, real device vs emulator trade-offs, mobile app lifecycle, network conditions.

  3. 3
    Automation and tooling— 12 min

    Appium driver model, locator strategy for mobile, gestures, CI infrastructure.

  4. 4
    Mobile-specific failures— 10 min

    Permissions, interruptions, memory/battery, deep links, OS-version edge cases.

  5. 5
    Wrap-up— 6 min

    Candidate questions and interviewer summary.

// INTERVIEW QUESTIONS

  1. 01

    What is the practical difference between testing on a real device versus an emulator or simulator? When do you use each?

  2. 02

    How does device fragmentation affect your mobile test strategy? How do you decide which devices to cover?

  3. 03

    Walk me through how Appium works at a high level — the client, server, and native driver layers. Why does understanding this matter for test reliability?

  4. 04

    How do you locate elements in an Appium test? What locator strategies are most stable for iOS and for Android?

  5. 05

    A test passes on a Pixel 6 but fails on a Samsung Galaxy A52. Walk me through how you diagnose the difference.

  6. 06

    How do you test a swipe-to-dismiss gesture in Appium? What API do you use and what do you assert?

  7. 07

    How do you handle push notification permission prompts and system alerts in mobile automation?

  8. 08

    What mobile-specific failure modes do you always include in your test plan that junior engineers often miss?

  9. 09

    How do you integrate a mobile automation suite into CI? What are the infrastructure challenges that do not exist for web automation?

// EXPECTED ANSWER POINTS

Compare your answers to these points — one per question, in order.

  1. Emulators and simulators: fast, free, reproducible, no battery/camera/real-sensor fidelity, no OEM skin behaviour. Real devices: catch GPU rendering bugs, real network conditions, OEM-specific crashes (e.g. Qualcomm-specific memory allocation), touch latency differences. Strategy: emulators for fast feedback and smoke tests; real devices for release sign-off and critical path. Cloud device farms (BrowserStack, Sauce Labs, AWS Device Farm) provide breadth without physical lab overhead.

  2. Device fragmentation on Android: hundreds of OEM skins (Samsung OneUI, Xiaomi MIUI), different API levels, different screen densities and aspect ratios, varied keyboard and permissions behaviour. Build a device matrix from real user analytics: cover the top 80% of user sessions by OS version and manufacturer. Tier devices: T1 (must pass every build), T2 (pass on release), T3 (smoke only). iOS fragmentation is lower but OS adoption rate and screen sizes (mini, standard, Pro Max) still matter.

  3. Appium architecture: the test client sends WebDriver protocol commands to the Appium Server. The Appium Server translates these into native driver calls — XCUITest for iOS, UIAutomator2 or Espresso for Android. The native driver executes against the app on the device. The driver layer is the reliability risk: Appium and driver versions must be tightly pinned. A driver update can silently change element-finding behaviour or gesture handling, breaking tests without any app change.

  4. Most stable mobile locators: accessibility ID (maps to accessibilityIdentifier on iOS, contentDescription on Android) — survives app refactors and is semantically meaningful. Resource ID on Android (com.example.app:id/submit_button) — stable within an app version. XPath: last resort on mobile — slow, brittle, breaks on minor layout changes. Avoid class-based position selectors. Advocate with developers to add accessibility labels to interactive elements; it improves both testability and accessibility audit scores.

  5. Diagnosis order: (1) Check screen resolution and density — the element may be off-screen or in a different position on the A52 screen size. (2) Check Android API level — A52 may run a different Android version with changed permission or animation behaviour. (3) Use Appium Inspector on both devices to compare the element tree — Samsung OneUI often wraps standard components in additional layers, changing the locator path. (4) Check device logcat for any native crash, ANR, or permission denial. (5) Confirm the OEM keyboard or system dialog is not occluding the element.

  6. Use the W3C Actions API in Appium 2.x — not the deprecated TouchAction class. For iOS: driver.executeScript('mobile: swipe', { direction: 'left', element: elementId }). For Android: driver.executeScript('mobile: swipeGesture', { left, top, width, height, direction: 'left', percent: 0.75 }). Assert the resulting state — the element should no longer be visible, or a new view should be present. Never assert the gesture itself; assert the application state that the gesture is supposed to produce.

  7. iOS permission alerts: use driver.executeScript('mobile: alert', { action: 'accept' }) or add the expected alert to Appium's auto-accept list. XCUITest can also dismiss alerts via XCUITest API directly. Android POST_NOTIFICATIONS permission (API 33+) appears as a standard permission dialog — handle with UiAutomator2's uiautomator selector or grant at install time via adb shell pm grant. Always test the denied path: the app must degrade gracefully without the permission, with no crash and a clear message to the user.

  8. Often-missed mobile failure modes: (a) App backgrounding and foregrounding — some screens lose state and do not restore correctly. (b) Incoming call or SMS mid-flow — interrupts the app and may leave it in an inconsistent state. (c) Low-memory kill — Android's low-memory killer can terminate background processes; return to a killed app should restore state or restart cleanly. (d) Network switching (WiFi to mobile data mid-session) — especially relevant for long operations like file uploads. (e) Dark mode on Android/iOS — custom components sometimes render incorrectly. (f) Large-text accessibility setting — UI elements truncate or overlap. (g) Timezone or locale change on device — exposes bugs in date pickers, scheduling, and localised content.

  9. Mobile CI infrastructure challenges beyond web: (a) iOS simulators require a macOS runner — Linux/Windows CI cannot run them. Use GitHub Actions macos-latest or a Mac build agent. (b) Android emulators need hardware acceleration (KVM on Linux); Docker containers require --device /dev/kvm. (c) Cloud device farms (BrowserStack Automate, Sauce Labs) solve the hardware problem but add latency and cost per minute. (d) The app binary (IPA/APK) must be built in the same pipeline before tests run — add a build stage before the test stage. (e) Parallel execution means multiple devices in parallel, not multiple threads on one device — shard by device target, not by test file alone.

// SCORING RUBRIC

Strong (4-5)

Gives a concrete device matrix strategy tied to user analytics. Explains the Appium driver model accurately — client, server, native driver, and why pinning matters. Can articulate iOS vs Android locator differences. Names real mobile failure modes beyond 'it crashes.' Has integrated mobile tests into CI with real infrastructure decisions.

Acceptable (3)

Understands Appium basics and real-device vs emulator trade-offs. Has tested on real devices. May not know the W3C Actions API by name but can explain the gesture problem. CI integration knowledge is high-level. Locator strategy is correct but not deeply considered.

Weak (1-2)

Has only ever tested on emulators and considers that sufficient for release sign-off. Cannot name a stable mobile locator strategy beyond positional XPath. Does not know the difference between XCUITest and UIAutomator2. Has never handled permissions or interruptions in tests. Cannot name a mobile-specific failure mode beyond basic crashes.

// RED FLAGS

Answers or behaviours that signal a weak candidate to the interviewer.

  • Has only tested on emulators/simulators and considers that sufficient without real-device verification.

  • Cannot name a stable mobile locator strategy — only knows positional XPath or class-based selectors.

  • Does not know the difference between iOS Simulator and Android Emulator at an architectural level.

  • Cannot name any mobile-specific failure mode beyond 'app crashes.'

  • Has never debugged an Appium session using Appium Inspector or device logs (logcat/Console.app).

  • Believes device fragmentation is not a meaningful concern for mobile test strategy.

// FOLLOW-UP QUESTIONS

Questions a strong interviewer adds if you answered the main round well.

  1. 01

    How would you test an app feature that uses biometric authentication — Face ID on iOS or fingerprint on Android?

  2. 02

    What is Espresso, and when would you choose it over Appium for Android testing?

  3. 03

    How do you test deep links and custom URL schemes in a mobile app?

  4. 04

    How do you handle flaky tests caused by slow animations in Appium? What Appium or driver settings are involved?

// SELF-ASSESSMENT CHECKLIST

Tick these off mentally after the mock. Be honest — this is for you, not for the interviewer.

  • I explained the real-device vs emulator trade-off with a specific example of what each misses, not a generic comparison.
  • I described a device matrix strategy tied to user analytics or session data rather than vaguely covering 'many devices.'
  • I explained the Appium architecture accurately — test client, Appium Server, and the native driver layer — and why driver version pinning matters.
  • I named accessibility ID as the preferred mobile locator and explained why positional XPath is a last resort on mobile.
  • I described at least three mobile-specific failure modes beyond basic crashes, including at least one system-level interruption.
  • I gave a concrete CI infrastructure answer for mobile — addressing the macOS requirement for iOS or the KVM requirement for Android emulators.

// RECOMMENDED NEXT MOCK

🤖 Automation QA mock interview

Mid · 45 min

// STUDY THESE NEXT

Mobile QA role track →Mobile QA prep plan →All question banks →Practical assignments →