// Interview Prep/Prep plans/14-Day Mobile QA Prep Plan
🗓️ 14-Day Mobile QA Prep Plan
Mid-to-senior mobile QA engineers preparing for a structured interview loop. Assumes you have some iOS or Android testing experience — this plan sharpens your device strategy thinking, builds interview-ready Appium artefacts, and targets the specific question banks interviewers use for mobile QA rounds.
// GOAL
Arrive at the Mobile QA interview with a working Appium test suite on GitHub, a documented device matrix, and confident answers to questions on mobile fundamentals, gesture automation, OS fragmentation, and cloud device farms.
// THE PLAN
Build a clear mental model of mobile testing before touching any device or tool
// STUDY
- Native, hybrid, and PWA architectures: how the technology stack changes your locator strategy, tool selection, and which classes of bug automation can and cannot surface
- iOS vs Android platform differences: XCUITest vs UiAutomator2 as the underlying driver, inspector tools (Appium Inspector, Xcode Accessibility Inspector, Android Studio Layout Inspector), and the failure modes that differ between platforms
- Real device vs emulator vs simulator: coverage, speed, cost, and flakiness trade-offs — when each is the right choice and how to justify the decision to a product manager
- Device matrix fundamentals: OS version market share (StatCounter, App Analytics), Android manufacturer fragmentation, screen-size breakpoints, and how to build a risk-weighted matrix for a constrained device budget
// PRACTISE
- Read the Mobile QA role page and map your current experience against each listed skill — mark gaps honestly, as these become your study targets for Days 8–11
- For a food-delivery app, design a 6-device test matrix covering both iOS and Android: justify every device in one sentence (OS coverage, manufacturer representation, or screen-size breakpoint)
- List 5 mobile-specific failure modes that would NOT appear in browser-based E2E testing — for example: OS permission prompt interrupting a checkout flow, background/foreground state change losing unsaved form data, or a deep link routing to the wrong screen after cold start
Deliverable
A 6-device test matrix with written justifications for every device, and a list of 5 mobile-specific failure modes with one-sentence explanations — use these as talking points in the interview.
Write a working Appium test and understand the architecture behind it
// STUDY
- Appium architecture: the client library → Appium server → platform driver (UiAutomator2 for Android, XCUITest for iOS) chain — understanding what each layer does when a command fails helps you diagnose errors quickly
- Element location strategies: accessibility IDs (most stable), resource-id, UI Automator text matchers, XPath — the stability trade-offs of each, and why interviewers ask about this specifically
- W3C capabilities (AppiumOptions): platformName, deviceName, app, automationName, noReset — the most common misconfiguration mistakes and how they surface as driver startup errors
- Handling async app states: explicit waits for element visibility, polling through loading spinners, and why implicit waits cause more problems than they solve in mobile automation
// PRACTISE
- Install Appium and write a login test against the Appium demo app or SwagLabs mobile app on an Android emulator: find the username field, enter credentials, tap Login, and assert the home screen title is visible
- Deliberately use an unstable XPath locator to find an element, run the test until it is fragile or fails, then refactor to use an accessibility ID — document the locator change and why it improves stability
- Add an explicit wait before your final assertion: wait until the home screen element is visible with a 10-second timeout — verify the test still passes after introducing a 3-second artificial delay in the app startup
Deliverable
A working Appium login test committed to GitHub using accessibility IDs for all locators and an explicit wait before the final assertion — the foundation for the gesture and interrupt tests in Days 8–11.
Test the mobile-specific scenarios that a standard login test never covers
// STUDY
- Gesture testing: Appium W3C Actions API for swipe, pinch-to-zoom, long-press, and scroll-to-element — when gesture actions are brittle and why element-based scroll is usually more reliable
- Interrupt and permission handling: incoming call during a form submission, push notification during checkout, OS permission dialog on first launch, low battery alert — how to trigger each in an emulator and what the expected app behaviour should be
- Cloud device farms: BrowserStack App Automate, Sauce Labs Real Device Cloud — connecting your existing Appium suite, reading remote session logs, and distinguishing farm-specific flakiness from genuine app bugs
- Mobile performance indicators: app cold start time, frame rate jank (look for dropped frames in the developer overlay), memory pressure warnings, and network condition simulation with emulator settings or Charles Proxy
// PRACTISE
- Extend your Appium test suite with a swipe gesture (e.g. swipe through an onboarding carousel to reach page 3) and a scroll-to-element (e.g. scroll a product list until a specific item is visible, then tap it)
- Simulate a network interruption mid-flow using the Android emulator's network condition controls or Charles Proxy — log what the app does (error message, silent failure, retry), and file a structured bug report if the error handling is poor
- Run your Appium suite remotely on BrowserStack or Sauce Labs against 2 different device and OS combinations from your Day 1 matrix — compare the session logs and note any differences in element timing or gesture behaviour
Deliverable
Test suite extended with at least one gesture test and one scroll-to-element test, running on a minimum of 2 cloud device configurations — plus a documented network-interruption finding.
Consolidate weak areas, work through the question banks, and simulate the interview
// STUDY
- Mobile bank: focus on questions about Appium architecture, locator strategy trade-offs, device matrix design rationale, and real device vs emulator differences — these are the questions that separate mid from senior candidates
- Test design bank: applying equivalence partitioning and boundary-value analysis to mobile inputs — character limits on text fields, touch target minimum sizes, and keyboard type switching
- Behavioural bank: emulator-pass / real-device-fail scenarios, farm-introduced flakiness, a device matrix growing faster than the team can maintain — practise structured STAR answers
- Re-read the Appium capabilities and gesture documentation for any techniques that felt fragile or unclear during Days 4–11
// PRACTISE
- Answer 10 questions aloud from the mobile, manual, and test design question banks — time yourself at 90 seconds per answer and note every question where you stalled or gave a vague answer
- Identify your 5 weakest answers and write a worked example for each, drawing on the test suite and device matrix you built during the plan
- Run a 30-minute timed mock: given a brief for a new biometric login feature (Face ID / fingerprint), write a session charter for a 20-minute exploratory test and then walk through it aloud as if debriefing an interviewer — cover happy path, failure modes, and accessibility
Deliverable
Written answers to your 5 weakest questions and a debrief document from the biometric login exploratory mock — structured as you would present it to a hiring panel.
Capstone: simulate the technical interview task
Mock task
Set a 45-minute timer. You have access to a simple to-do list app installed on an Android emulator (use any open-source demo app — the WNBA app, the Appium demo app, or a simple open-source to-do). Part 1 (20 minutes): run an exploratory session using a written charter — 'Explore the add-item, edit-item, and delete-item flows, focusing on edge cases, keyboard dismissal behaviour, and gesture reliability on a 5.5-inch screen.' Log every finding as a structured bug report: title, severity, steps to reproduce, expected vs actual result. Part 2 (20 minutes): write and run a single Appium test that adds a new item, verifies it appears in the list, edits its text, verifies the updated text, and deletes it — using accessibility IDs for all locators and explicit waits after each action. Part 3 (5 minutes): write a one-paragraph self-review — what your test does NOT cover, what manual checks it should always be paired with, and what you would automate next if given another hour.