Mobile App — Build an E2E Test Pass

Plan and build an end-to-end test pass for a mobile app: pick the right framework for the platform, automate against an emulator/simulator, handle the mobile-specific traps (gestures, waits, fragmentation), and reason about what only a real device can tell you.

Role

Mobile QA engineer

Difficulty

Intermediate

Time limit

~120 min

Scenario

You've joined the QA team for a mobile app called TrailMate, an outdoor-activity tracker with a login, a list of saved trails, a detail screen, and a 'start activity' flow that uses the device's location. There is no automated mobile testing yet, and the team keeps shipping regressions that only show up on certain devices. Your job is to bring a first, credible mobile E2E pass into place: choose a framework that fits the app and team, automate the core flows against an emulator or simulator, handle the gestures and synchronisation that make mobile tests flaky, and be explicit about which checks genuinely need a real device. The deliverable is a small but trustworthy suite plus the reasoning behind your tooling and device choices — not a giant suite that's green for the wrong reasons.

Requirements

1.State the app type (native / hybrid / mobile web) for your target and justify, in one or two sentences, the framework you chose for it (Appium, Espresso/XCUITest, Detox, or Maestro).
2.Stand up an emulator or simulator (or a device-cloud session) and confirm your framework can launch the app and find elements on it.
3.Automate at least three core flows (e.g. login, view a list + open a detail, and a gesture-driven flow like swipe-to-delete or scroll-to-load), asserting on real outcomes rather than just that a screen appeared.
4.Use stable locators: prefer accessibility ids over brittle XPath, and document any place you had to fall back to XPath and why.
5.Demonstrate correct synchronisation: replace any fixed sleep with a condition/element wait, and show one case where a naive sleep would have made the test flaky.
6.Include at least one gesture interaction (tap-and-hold, swipe, scroll-into-view, or rotation) and confirm the test scrolls off-screen elements into view before asserting.
7.Write a short real-device-vs-emulator analysis (at least four sentences): which of your tests are trustworthy on an emulator/simulator, and which checks (performance, location/sensors, true touch, network conditions) you would only trust on a real device, and why.
8.Recommend a mobile CI setup: what runs on every PR (against an emulator/simulator), what runs against a real-device cloud and when, and a sensible device/OS matrix rather than every combination.

Starter data

›Android emulator via Android Studio's AVD Manager; iOS simulator via Xcode. Both are free and scriptable in CI.
›Appium uses the WebDriver protocol — the same client patterns as Selenium, pointed at a mobile driver (UiAutomator2 for Android, XCUITest for iOS).
›Maestro is the fastest way to get a first flow running: declarative YAML with built-in waits, if you want to minimise setup.
›Locator preference: accessibility id > platform id (resource-id / name) > class chain / UiAutomator > XPath (last resort).

Expected deliverables

✓The app-type + framework justification.
✓A runnable suite of at least three core-flow tests against an emulator/simulator, with stable locators.
✓The synchronisation demonstration (condition wait vs the naive sleep that would flake).
✓At least one gesture interaction with scroll-into-view before assertion.
✓The real-device-vs-emulator analysis and the mobile CI recommendation with a device/OS matrix.

Evaluation rubric

Dimension	What reviewers look for
Framework fit	Does the chosen framework match the app type and team? A weak submission reaches for Appium reflexively without reasoning. A strong one ties the choice to the app (native vs hybrid vs RN), the team's languages, and whether one cross-platform suite or two native ones makes sense.
Locator stability	Are elements found by stable identifiers? A weak answer leans on brittle absolute XPath that breaks on any UI change. A strong one prefers accessibility ids, uses platform ids next, and treats XPath as a documented last resort.
Synchronisation discipline	Does the suite wait on conditions rather than sleep? A weak submission sprinkles fixed sleeps that pass locally and flake on a loaded CI emulator. A strong one waits for elements/conditions and can show exactly where a naive sleep would have caused flakiness.
Gesture and screen handling	Are mobile-specific interactions handled correctly? A weak answer assumes everything is on-screen and tappable. A strong one scrolls off-screen elements into view before asserting and exercises a real gesture (swipe/long-press/rotate) the app depends on.
Real-device judgement	Does the candidate know what an emulator can and can't tell them? A weak answer treats emulator green as full confidence. A strong one identifies the checks that need real hardware — performance, sensors/location, true touch, real networks — and says why.
CI and matrix reasoning	Is the CI recommendation realistic? A weak answer says 'run it in CI'. A strong one splits fast PR runs (emulator) from scheduled/pre-release real-device runs, and picks a representative device/OS matrix instead of chasing every combination.

Sample solution outline

›App type: native Android + iOS -> chose Appium for one cross-platform suite in the team's existing JS/TS, with Maestro considered for speed.
›Stood up an Android emulator (Pixel, API 34) via AVD; confirmed Appium launches TrailMate and finds elements by accessibility id.
›Flow 1 login: enter creds (accessibility ids), assert the trails list screen and a known trail appear. Flow 2: open a trail detail, assert title/distance. Flow 3: swipe-to-delete a saved trail, assert it's gone from the list.
›Locators: accessibility ids for inputs/buttons; one XPath fallback for an un-id'd label, documented as a dev follow-up to add an id.
›Sync: replaced a sleep(3) after login with a wait for the trails-list container; noted that on a loaded CI emulator the sleep flaked while the wait held.
›Gesture: scroll-into-view for a trail far down the list before tapping; swipe gesture for delete.
›Real-device analysis: login/list/detail trustworthy on emulator; the 'start activity' GPS flow and scroll performance only trustworthy on a real device.
›CI: Appium smoke on an emulator on every PR; full suite on a BrowserStack/Sauce real-device matrix (2 Android + 1 iOS, current + 1 older OS) pre-release.

Common mistakes

Reaching for Appium by default without checking whether a native tool or Maestro fits the app and team better.
Using brittle absolute XPath instead of accessibility ids, so tests break on any layout tweak.
Fixed sleeps instead of condition waits — the number-one source of flaky mobile tests on CI emulators.
Asserting only that a screen appeared, not that the right data/outcome is present.
Assuming an element is absent when it's just off-screen — not scrolling it into view first.
Treating emulator-green as full confidence and never reasoning about what needs a real device.

Submission checklist

App type stated and framework choice justified
Emulator/simulator (or device-cloud) running the app under the framework
At least three core-flow tests asserting on real outcomes
Stable locators (accessibility ids preferred; XPath fallbacks documented)
A condition-wait replacing a naive sleep, with the flakiness case explained
At least one gesture + scroll-into-view before assertion
Real-device-vs-emulator analysis (4+ sentences)
Mobile CI recommendation with a device/OS matrix

Extension ideas

+Run the same Appium suite against a real-device cloud (BrowserStack/Sauce/LambdaTest) and compare results to the emulator run.
+Add the suite to a mobile CI pipeline (Bitrise, or GitHub Actions with an emulator) and gate a PR on the smoke tests.
+Test the hybrid/webview portion of the app if it has one, switching between native and webview contexts.