Appium Mobile Testing Interview Questions for 5 Years Experience (2026)

Short answer: keep tests platform-neutral and push differences into screen objects. Tests call loginScreen.loginAs(user); an interface has Android and iOS implementations, picked from config at startup.

public interface LoginScreen { HomeScreen loginAs(User u); }

public final class Screens {
    public static LoginScreen login(AppiumDriver d) {
        return Platform.current() == Platform.IOS ? new IosLoginScreen(d) : new AndroidLoginScreen(d);
    }
}

Shared accessibility ids across both apps remove most of the duplication - agree on them with developers early.

Short answer: one session per device, with no port clashes. Each Android session needs its own udid and systemPort; each iOS session needs its own udid and wdaLocalPort. Driver instances must be per-thread, not static.

UiAutomator2Options opts = new UiAutomator2Options()
    .setUdid(device.udid())
    .setSystemPort(8200 + workerIndex);   // unique per parallel worker

Common failure: two sessions using the default systemPort - the second session takes over the first device's instrumentation and both tests fail.

Short answer: run the bulk of functional tests on emulators/simulators (fast and cheap), and run a smaller set on real devices for things emulators do not show well: camera, biometrics, push notifications, real network conditions and manufacturer-specific behaviour.

Choose real devices from your own analytics (top OS versions and models among your users), not from a generic list. A cloud farm makes sense when you need that device range without maintaining hardware; weigh cost per minute against how often the suite runs.

• Animations: turn off Android animations on test devices; they cause clicks to land mid-transition.
• Permission dialogs: grant them up front (autoGrantPermissions on Android) instead of tapping them in each test.
• App state: leftover data from a previous test; reset or create fresh data.
• Keyboard: the soft keyboard covering the next field.
• Device health: low storage or a device that has been running for days.

Track which tests fail intermittently per device, so you can tell an app bug from a sick device.

Short answer: instead of tapping through login and menus in every test, open the screen under test directly, with state prepared through an API.

// UiAutomator2
driver.executeScript("mobile: deepLink", Map.of(
    "url", "myapp://orders/ORD-1001",
    "package", "com.example.shop"));

Keep a few full end-to-end journeys that go through the real UI; use deep links for everything that is testing a single screen.

Short answer:

1. Build the test build of the app (APK/IPA) once and store it as an artifact.
2. Run unit tests and API tests first - they are faster and fail earlier.
3. Start emulators (or reserve farm devices), install the artifact, run a smoke set on every merge.
4. Run the full device matrix nightly or before release.
5. Publish JUnit XML, screenshots and device logs (logcat / syslog) for every failure.

iOS builds need code signing set up for the test devices; plan this with whoever owns release builds.

Short answer: combine tools: the Android emulator can simulate network speed and latency, many device farms offer network profiles, and a proxy can slow or fail specific API calls. Test what the user sees - loading states, retry buttons, no duplicate orders after a timeout.

Write expected results as behaviour ("the Pay button is disabled while the request is in progress"), not as timing numbers you have not measured.

Short answer: keep Appium for user journeys that cross many parts of the app, and push detailed checks down to unit tests, API tests and the platforms' own UI test tools (Espresso, XCUITest) owned with developers. When a UI test fails, ask whether a lower-level test could have caught it faster, and add that test.