All jobs / Automation developer

Mobile Automation interview questions

Mobile Automation questions a Automation developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. When is an emulator enough for a mobile test, and when do you need a real device?

    The strongest answer: Emulators are fine for functional flows, layouts and regression breadth — fast and disposable. Real devices are for the physical things: performance on real silicon, sensors and camera, biometrics, push, poor networks, battery and heat

    Why it works: Exactly — split by what the test depends on, not by how important the test feels.

    • Split by what the test depends on.
    • Emulators: breadth, layouts, logic.
    • Devices: sensors, performance, battery.
    • Speed and fidelity are both real costs.

  2. Walk me through what happens between your Appium test calling click and the button being tapped on the device.

    The strongest answer: The client library sends a WebDriver command over HTTP to the Appium server, which routes it to the platform driver for that session — UiAutomator2 on Android, XCUITest on iOS — and that drives the app and returns the result

    Why it works: Right — client, server, platform driver, device. Knowing the hops is how you read an Appium stack trace.

    • Client, server, platform driver, device.
    • Commands travel as WebDriver over HTTP.
    • UiAutomator2 on Android, XCUITest on iOS.
    • Read failures by naming the hop.

  3. Your Appium suite locates elements with long XPath expressions, and half of them break whenever a screen is re-laid out.

    What do you ask the developers for?

    The strongest answer: An accessibility id on every element the tests touch — content-desc on Android, accessibilityIdentifier on iOS — so one locator works on both platforms and survives a re-layout

    Why it works: Right — and it is the one locator strategy in Appium that is genuinely cross-platform.

    • Ask for accessibility ids.
    • content-desc on Android, identifier on iOS.
    • One locator for both platforms.
    • XPath follows layout; ids do not.

  4. When do you bother with Selenium Grid / a device farm?

    The strongest answer: When you have a real matrix — browsers or devices customers use that your local runner cannot cover — not because “grid” looks senior on a slide

    Why it works: Exactly. A farm is for diversity you need. Parallel Chrome-on-Chrome is usually just more workers.

    • Farms for real matrix risk.
    • Develop locally.
    • Do not skip a real device you owe.
    • Same-browser × N is workers, not Grid.

  5. A gesture-heavy Android suite is flaky: taps land on a view that is still sliding into place.

    What do you change, and what does it cost you?

    The strongest answer: Turn the device animation scales off for the run — developer settings or the driver capability for it — and still wait for the element to be ready; the cost is that nothing tests the animation, so keep one test that does

    Why it works: Right — remove the cause, keep the readiness check, and be honest about the fidelity you dropped.

    • Remove the animation, not the symptom.
    • Turn animation scales off for the run.
    • Still wait for the element to be ready.
    • Name the fidelity you gave up.

  6. You are starting mobile automation for a product with separate native Android and iOS apps over one shared backend.

    One Appium suite for both platforms, or Espresso and XCUITest per platform?

    The strongest answer: It turns on how much the two apps share. Same flows, one Appium suite keeps the journeys in one place; diverged teams and UIs, native suites run faster and closer to the code. Either way, shared rules are tested once at the API

    Why it works: Right — the answer turns on shared flows and team shape, and the backend carries the rules either way.

    • Shared flows favour one suite.
    • Diverged apps favour native runners.
    • Test shared rules once, at the API.
    • Own the choice, and say why.

  7. Your mobile matrix has grown to 22 device-and-OS combinations, every one running the full pack, and the bill and the runtime have both doubled.

    How do you decide what stays?

    The strongest answer: Rebuild it from our own install-base data — the OS versions and screen sizes our users have, the oldest OS we still support, one low-end device — then tier it: a couple every run, the rest before a release

    Why it works: Exactly — evidence picks the list, tiering controls the bill, and a review date stops it ossifying.

    • Let install-base data pick devices.
    • Keep the oldest OS you support.
    • Include one low-end device.
    • Tier the matrix; review it on a date.