Appium Mobile Automation Interview Questions for Automation Testing

Show answer

Appium is an open-source tool for automating native, hybrid and mobile web apps on Android and iOS using the W3C WebDriver protocol. Your Java test sends HTTP commands to the Appium server, which forwards them to a platform driver such as UiAutomator2 for Android or XCUITest for iOS. That driver talks to the device and returns results. Because it follows WebDriver, Selenium testers can reuse locators, waits and framework design.

What is the difference between native, hybrid and mobile web apps from a testing point of view?

Show answer

A native app is built with platform SDKs and is tested through native locators like accessibility id or resource-id. A mobile web app runs in the device browser, so you automate it much like desktop Selenium with mobile Chrome or Safari. A hybrid app wraps web content inside a native shell, so tests switch between the NATIVE_APP context and a WEBVIEW context. Knowing the type decides your driver, locators and setup.

What are Appium capabilities and which ones are essential to start a session?

Show answer

Capabilities are key-value settings sent when creating a session that tell Appium what to automate. Essential ones are platformName, appium:automationName (UiAutomator2 or XCUITest), appium:deviceName or appium:udid, and either appium:app (path to the apk or ipa) or appPackage and appActivity for an installed Android app. In Appium 2 non-standard capabilities need the appium: prefix. In Java you usually set them through UiAutomator2Options or XCUITestOptions.

Which locator strategies does Appium support and which should you prefer?

Show answer

Appium supports accessibility id, id (resource-id on Android), class name, XPath, Android UiAutomator selectors, iOS predicate strings and iOS class chains. Prefer accessibility id because it is fast, works across Android and iOS and also improves app accessibility. Next use resource-id or iOS predicates. Use XPath only as a last resort because it walks the whole UI tree and is slow and brittle, especially on iOS.

Your team asks whether mobile tests should run on emulators or real devices. What do you recommend?

Show answer

Use both, for different purposes. Emulators and simulators are cheap, fast to reset and easy to run in CI, so they suit smoke and regression runs on every commit. Real devices reveal issues emulators hide: performance on low-end hardware, camera, biometrics, push notifications, network changes and vendor-specific Android skins. A common plan is emulators in the pull request pipeline and a nightly run on a small matrix of real devices covering the most-used models.

What are appPackage and appActivity in Android automation?

Show answer

appPackage is the unique application id of an Android app, such as com.example.shop, and appActivity is the activity screen that Appium launches first, such as .MainActivity. Together they let Appium start an app that is already installed without passing the apk path. You can find them with adb shell dumpsys window or by reading the manifest. A wrong activity name is a common reason a session fails to start.

What is Appium Inspector and how do you use it?

Show answer

Appium Inspector is a desktop or web tool that connects to an Appium server with your capabilities and shows a live screenshot of the app with its element tree. Clicking an element shows its attributes such as accessibility id, resource-id, text and bounds, and suggests locators. You can also try taps and swipes interactively. Testers use it to find stable locators and to check whether an element is really present before writing code.

A runtime permission pop-up appears on first launch and breaks your Android tests. How do you handle it?

Show answer

The cleanest fix is the capability appium:autoGrantPermissions set to true, which grants all permissions the app declares at install time. If you need to test the permission flow itself, handle the dialog explicitly by waiting for the Allow button using its resource-id and clicking it. Another option is granting a specific permission with adb shell pm grant before the test. Avoid blind try-catch around taps, because it hides real failures.

The on-screen keyboard hides the login button in your mobile test. What do you do?

Show answer

Call driver.hideKeyboard() after typing, or check driver.isKeyboardShown() first so the call does not fail when no keyboard is open. On Android you can also set appium:hideKeyboard or use a capability for the unicode keyboard so the soft keyboard does not appear. Alternatively press the keyboard's Done or Enter key, or scroll the button into view. Pick one approach and put it in a helper so all tests behave the same.

What are the UiAutomator2 and XCUITest drivers in Appium?

Show answer

They are the platform drivers that actually control the device. UiAutomator2 drives Android by installing a small server app on the device that uses Google's UiAutomator framework. XCUITest drives iOS through Apple's XCTest framework via WebDriverAgent, which needs Xcode and signing for real devices. In Appium 2 they are installed separately with appium driver install, so each project picks only the drivers and versions it needs.

What changed in Appium 2 compared with Appium 1?

Show answer

Appium 2 split the monolithic server into a core plus separately installed drivers and plugins, managed with appium driver install and appium plugin install. It dropped the old JSON Wire Protocol in favour of W3C WebDriver only, so vendor capabilities need the appium: prefix. The default base path changed from /wd/hub to /. Old TouchAction and MultiTouchAction were removed from the Java client, so gestures use W3C Actions or mobile: commands.

How do you switch between native and webview contexts in a hybrid app?

Show answer

// Requires the webview to be debuggable in the app build Set<String> contexts = driver.getContextHandles(); for (String ctx : contexts) { if (ctx.startsWith("WEBVIEW")) { driver.context(ctx); break; } } driver.findElement(By.cssSelector("#email")).sendKeys("qa@test.com"); // back to native controls driver.context("NATIVE_APP");

What is the difference between noReset and fullReset in Appium?

Show answer

By default Appium clears app data between sessions but keeps the app installed. noReset set to true keeps app data and login state, which speeds up tests but can leak state between them. fullReset set to true uninstalls and reinstalls the app, giving the cleanest state but adding time. A common approach is noReset for fast suites with explicit cleanup in the test, and fullReset only for first-launch or onboarding scenarios.

How would you explain to a manager why mobile automation estimates are higher than web estimates?

Show answer

Situation: a manager questioned why my mobile estimate was nearly double the web one. Task: justify it with facts. Action: I listed the extra work: two platforms with separate locators, device and OS version matrix, slower sessions, app builds and signing, gestures and permissions, and device lab maintenance. I showed timings from a pilot of five tests. Result: the manager accepted a phased plan starting with Android smoke tests, and later estimates were trusted because they were data-backed.

Why is XPath slow in Appium and what should you use instead?

Show answer

For every XPath query Appium must fetch the full page source of the app, convert it into an XML document and then evaluate the expression, which can take seconds on large screens and is even slower on iOS. Index-based XPath also breaks when layouts change. Use accessibility id first, then resource-id, Android UiAutomator selectors or iOS predicate strings and class chains, which are evaluated natively on the device and are much faster.

An element is visible in Appium Inspector but your test throws NoSuchElementException on the device. What do you check?

Show answer

First check timing: the screen may still be loading, so add an explicit wait for presence. Then check context: in a hybrid app the element may be in a webview while you are in NATIVE_APP. Confirm the locator matches exactly, including package prefix in resource-id. The element may be off screen in a list, so scroll first. Also check that the Inspector session used the same app build, language and device size as the test.

Mobile tests pass on the emulator but fail on a low-end real device. How do you investigate?

Show answer

Low-end devices are slower, so fixed waits and short timeouts expire before screens render. Replace sleeps with explicit waits and increase timeouts sensibly. Check for vendor-specific pop-ups, battery optimisation dialogs or different keyboards on that brand. Compare screen size and resolution, since coordinate-based taps break. Collect device logs with adb logcat and screen recordings to see what the app was doing. Also check whether the app crashed due to low memory.

A mobile test fails intermittently because an animation is still running when you tap. How do you fix it?

Show answer

Wait for a stable end state instead of sleeping, for example wait until the target element is visible and enabled or until a spinner disappears. On test devices and emulators you can disable animations with adb shell settings put global window_animation_scale 0, along with the transition and animator scales. Ask developers for an idle indicator if needed. Disabling animations makes tests faster and more stable, but keep one manual check of the real animations.

Write Java code to start an Android Appium session using UiAutomator2Options.

Show answer

UiAutomator2Options options = new UiAutomator2Options() .setPlatformName("Android") .setAutomationName("UiAutomator2") .setDeviceName("Pixel_7_API_34") .setApp(System.getProperty("user.dir") + "/apps/shop.apk") .setAutoGrantPermissions(true) .setNewCommandTimeout(Duration.ofSeconds(120)); AndroidDriver driver = new AndroidDriver( new URL("http://127.0.0.1:4723"), options); driver.manage().timeouts().implicitlyWait(Duration.ZERO); // use explicit waits in tests driver.quit();

Write Appium code to scroll to an element by its text using UiScrollable on Android.

Show answer

// Scrolls the first scrollable container until the text is visible String selector = "new UiScrollable(new UiSelector().scrollable(true))" + ".scrollIntoView(new UiSelector().text(\"Order History\"))"; WebElement item = driver.findElement(AppiumBy.androidUIAutomator(selector)); item.click();

How do you capture a screen recording of a mobile test and attach it on failure?

Show answer

// Start before the test, stop and save only if it fails driver.startRecordingScreen(); // ... test steps ... String base64 = driver.stopRecordingScreen(); if (result.getStatus() == ITestResult.FAILURE) { byte[] video = Base64.getDecoder().decode(base64); Files.write(Paths.get("target/videos/" + result.getName() + ".mp4"), video); }

Tell me about a time you moved from web automation to mobile automation.

Show answer

Situation: my team needed Android regression tests and I only knew Selenium. Task: deliver a smoke suite in one month. Action: I learned Appium 2 setup, used Appium Inspector to find locators, asked developers to add accessibility ids, and reused our TestNG, POM and reporting structure with a new driver factory. Result: twenty smoke tests ran nightly on emulators within four weeks, and release smoke testing dropped from half a day to forty minutes.

Write Appium Java code to perform a vertical swipe using W3C Actions.

Show answer

// Swipe up from 80% to 20% of the screen height Dimension size = driver.manage().window().getSize(); int x = size.width / 2; int startY = (int) (size.height * 0.8); int endY = (int) (size.height * 0.2); PointerInput finger = new PointerInput(PointerInput.Kind.TOUCH, "finger"); Sequence swipe = new Sequence(finger, 1); swipe.addAction(finger.createPointerMove(Duration.ZERO, PointerInput.Origin.viewport(), x, startY)); swipe.addAction(finger.createPointerDown(PointerInput.MouseButton.LEFT.asArg())); swipe.addAction(finger.createPointerMove(Duration.ofMillis(600), PointerInput.Origin.viewport(), x, endY)); swipe.addAction(finger.createPointerUp(PointerInput.MouseButton.LEFT.asArg())); driver.perform(List.of(swipe));

How does Appium automate iOS apps and what setup is required?

Show answer

Appium uses the XCUITest driver, which builds and installs WebDriverAgent on the simulator or device. WebDriverAgent is a small XCTest-based server that receives commands and drives the UI. You need a Mac with Xcode, the iOS SDK and command line tools. For real devices you also need a valid Apple developer team, provisioning profile and signed WebDriverAgent. Most iOS setup failures come from signing problems or Xcode and iOS version mismatches.

Your 200 mobile tests across six devices take too long to finish. How would you speed them up?

Show answer

Run devices in parallel with one thread per device, each with its own udid, systemPort or wdaLocalPort. Use deep links or API calls to reach the screen under test instead of navigating through the UI every time. Prefer noReset with explicit data cleanup over reinstalling the app. Replace XPath with accessibility ids. Split the suite so pull requests run a small smoke set on emulators while the full device matrix runs nightly.

In a hybrid Android app, driver.getContextHandles() returns only NATIVE_APP. Why?

Show answer

The webview is probably not debuggable. Android only exposes a webview to automation when the app calls WebView.setWebContentsDebuggingEnabled(true), which developers usually enable only in debug builds, so ask for a debug or test build. Also wait until the webview screen is actually loaded before reading contexts. If the app uses Chrome custom tabs, that is a separate Chrome process, not a webview. Finally check that a compatible Chromedriver is available to Appium.

How do you run Appium tests in parallel on several Android devices?

Show answer

Give each device its own session: unique appium:udid, a separate appium:systemPort for UiAutomator2 and, for hybrid apps, a separate chromedriverPort. Store the driver in a ThreadLocal so threads never share it. Pass device details through TestNG parameters or a DataProvider and run with parallel="tests", one test tag per device. One Appium server can handle several sessions, or use a Selenium Grid 4 with Appium nodes or a cloud device farm for larger matrices.

How do you test deep links in a mobile app with Appium?

Show answer

On Android use the mobile: deepLink command with the URL and package, for example driver.executeScript("mobile: deepLink", Map.of("url", "shop://product/42", "package", "com.example.shop")). On iOS simulators driver.get with the custom URL opens it, though Safari may show a confirm dialog to handle. Then assert that the correct screen and data are shown. Deep links are also a great shortcut to reach deep screens quickly in other tests.

How would you design one mobile framework that serves both Android and iOS?

Show answer

Keep tests platform-neutral and push differences into page objects. Use Appium's @AndroidFindBy and @iOSXCUITFindBy annotations, or separate locator files per platform, behind one screen class. Create the driver through a factory that reads platform from configuration. Ask developers to add the same accessibility ids on both platforms so most locators are shared. Put gestures and waits in a common base screen, and tag tests that apply to only one platform.

Your company is debating a cloud device farm versus an in-house device lab. How do you advise?