All jobs / Mobile developer

Mobile Testing interview questions

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

  1. A bug “only happens on a phone.” What do you do first?

    The strongest answer: Reproduce on a real device (or a close farm device) with the same OS, density, and permissions — simulators miss sensors, memory pressure, and store-signed behaviour

    Why it works: Exactly. The simulator is a development tool, not the product. Device, OS, and signing matter.

    • Reproduce on hardware when the bug is device-shaped.
    • Match OS, density, and permission state.
    • Do not treat “works in simulator” as done.
    • Keep a small physical matrix even if you also have a farm.

  2. Which parts of a mobile app can you test without a device or a simulator, and what does that ask of the code?

    The strongest answer: Anything with no platform dependency — view models, mappers, validation, formatting — as long as the platform sits behind interfaces a test can substitute, so it runs as a plain unit test in seconds

    Why it works: Exactly — testability off-device is a design property, and the interface is what buys it.

    • Logic off the device, fast.
    • Keep logic out of screen classes.
    • Put the platform behind interfaces.
    • Save the device for UI tests.

  3. UI tests pass on a CI emulator API 35 and fail on a store-sideload Android 12 phone. What is the lesson?

    The strongest answer: The matrix is part of the product — I run a slice of UI tests on the oldest OS and a recent device, not only on the image that is convenient for CI

    Why it works: Exactly. Green on one image is not coverage. Claimed OS versions need a run.

    • CI image ≠ oldest claimed OS.
    • Keep a cheap extra API level in CI if you can.
    • Do not “fix” failures by dropping support in silence.
    • Quarantine flakes; do not delete the suite.

  4. You have a cloud device farm. What do you still keep on the desk?

    The strongest answer: At least one recent iPhone and one recent Android, plus the oldest OS you claim — farms miss cables, push provision, and “this build feels janky”

    Why it works: Exactly. Farms are coverage. Hands are judgement and the weird radios.

    • Farm for breadth.
    • Hands for feel, push, and cables.
    • Keep the oldest OS you advertise.
    • Do not skip a whole OS family.

  5. QA asks for “every device on the market.” How do you set the matrix?

    The strongest answer: By risk: claimed min OS, top store devices in our markets, one low-RAM, one tablet, and the OEM skins that have bitten us — I publish the matrix and the holes

    Why it works: Exactly. A matrix is a risk document. Name what you cover and what you do not.

    • Cover claimed min OS.
    • Cover real market share and known OEM traps.
    • Include low-RAM.
    • Write down the holes.

  6. The UI suite is red about one run in five, always on a different test, and re-running usually passes.

    How do you fix it?

    The strongest answer: Wait for conditions the app exposes — idle, an element on screen, a finished request — instead of sleeping, pin animations, locale and clock, and let each test create its own data

    Why it works: Right — most flakiness is timing plus shared state, and this removes both rather than hiding them.

    • Wait for conditions, never for time.
    • Turn off animations; pin locale and clock.
    • Each test makes its own data.
    • Never retry to hide flakiness.

  7. Finance asks why you rent a device farm and still buy phones. What is the one-sentence case?

    The strongest answer: The farm is coverage and regression; the desk phones are judgement, radios, and store-like signing — cutting either recreates the outage we already paid for

    Why it works: Exactly. Two tools, two jobs. Say that in the budget narrative.

    • Farm = breadth.
    • Hands = feel, radios, signing.
    • Budget both on purpose.
    • Name the outage you are buying down.

  8. QA proposes one Appium suite covering iOS and Android so the tests are written once. What is your call?

    The strongest answer: Native frameworks for the fast, deep checks the app teams own, and a cross-platform suite only for the few journeys that must be identical on both. One tool for everything trades speed and debuggability for sharing

    Why it works: Right — pick the tool per layer, and let the cost of a failing test being hard to debug count in the decision.

    • Match the tool to the layer.
    • Native for fast, deep checks.
    • Cross-platform for shared journeys.
    • Teams own their own tests.