Top 50 Appium & Mobile
Interview Questions

Mobile automation testing is the process of testing mobile applications (Android/iOS) automatically using software tools instead of human interaction to ensure functionality, usability, and consistency.

Mobile testing deals with device fragmentation, varying screen sizes, OS versions (iOS/Android), and hardware dependencies (battery, GPS, camera), while web testing primarily focuses on cross-browser compatibility and responsive design on desktops.

Native apps (built specifically for iOS/Android using Swift/Kotlin), Web apps (accessed via mobile browser), and Hybrid apps (web apps wrapped in a native container using frameworks like React Native or Ionic).

Appium is an open-source, cross-platform mobile test automation framework that supports testing of native, hybrid, and web applications for iOS and Android using the WebDriver protocol.

It is open-source, supports cross-platform testing (write once, run on iOS/Android), allows testing without modifying or recompiling the app source code, and supports multiple programming languages (Java, Python, JS).

Appium is an HTTP server written in Node.js that creates and handles WebDriver sessions. It receives REST API requests from client libraries (test scripts) and translates them into native commands for UiAutomator2 (Android) or XCUITest (iOS).

Appium supports any language that has Selenium WebDriver bindings, including Java, Python, JavaScript/Node.js, Ruby, C#, and PHP.

Selenium is specifically designed for automating web browsers on desktop OS, whereas Appium extends the Selenium WebDriver protocol to automate mobile applications on Android and iOS devices.

Desired Capabilities are a set of keys and values (JSON object) sent by the client to the Appium server to tell the server what kind of automation session to initiate (e.g., platformName, deviceName, appPackage, appActivity).

Android testing requires dealing with heavy device fragmentation, OS customizations, and uses UiAutomator2 via APKs. iOS testing deals with a controlled ecosystem, strict security permissions, requires a Mac machine, and uses XCUITest via IPAs or .app files.

Appium Inspector is a GUI tool that allows testers to inspect the UI elements of a mobile app, view their hierarchy, and generate XPath or ID locators needed for writing automation scripts.

Elements are identified using locator strategies such as Accessibility ID, ID (resource-id), XPath, Class Name, or platform-specific strategies like AndroidUIAutomator or iOSClassChain.

Standard locators include ID, XPath, and ClassName. Appium-specific locators include Accessibility ID (highly recommended), -ios predicate string, -ios class chain, and -android uiautomator.

UiAutomator2 is the standard Google-provided testing framework for Android automation. Appium uses the UiAutomator2 driver under the hood to interact natively with Android devices.

XCUITest is Apple's official UI testing framework for iOS applications. Appium wraps XCUITest to execute automation commands on iOS simulators and real devices.

You can start the Appium server either by launching the Appium Desktop application and clicking 'Start Server', or programmatically via the command line using the `appium` command in Node.js.

`findElement()` returns the first matching element and throws an exception if none is found. `findElements()` returns a list of all matching elements, or an empty list if none are found.

In Android, you use `UiScrollable` via the AndroidUIAutomator locator. In iOS, you can use `mobile: scroll` with direction parameters, or implement the TouchAction/W3C Actions API for gesture swipes.

You can handle standard OS alerts by switching the driver context to the alert (`driver.switchTo().alert()`) and using methods like `accept()` or `dismiss()`. For custom app pop-ups, you locate the alert buttons normally via standard locators.

Gestures are automated using the W3C Actions API (Sequence of Pointers and Moves) or platform-specific mobile commands like `mobile: swipe` for iOS. Older versions used the deprecated TouchAction class.

ADB is a command-line tool that lets you communicate with an Android device or emulator. It allows you to install/uninstall apps, pull/push files, and view device logs.

You must enable 'Developer Options' and 'USB Debugging' on the device, connect it via USB, and authorize the computer. You can verify the connection by running `adb devices` in the terminal.

An APK (Android Package Kit) is the file format used by Android for the distribution and installation of mobile apps. Appium requires this file to install the app under test.

The Package name is a unique identifier for the app (e.g., com.example.app). An Activity represents a single screen with a user interface within that app (e.g., MainActivity).

You can find them by opening the app on a connected device and running `adb shell dumpsys window | grep -E 'mCurrentFocus'` on Mac/Linux or similar findstr command on Windows.

Emulators are software programs mimicking device behavior, good for fast, early-stage functional testing. Real devices test actual hardware conditions like battery drain, network drops, and exact screen rendering.

You install an APK using the ADB command: `adb install <path_to_apk_file>`. To overwrite an existing installation, use `adb install -r <path>`.

Android-specific capabilities include `appPackage`, `appActivity`, `systemPort` (for parallel testing), `autoGrantPermissions`, and `automationName` (typically set to 'UiAutomator2').

You use the `adb logcat` command in the terminal to view real-time system logs. In Appium scripts, you can retrieve them programmatically via `driver.manage().logs().get('logcat')`.

It is a legacy GUI tool provided with the Android SDK to inspect the UI hierarchy of an Android screen and identify locators, largely replaced by Appium Inspector today.

A framework is a set of guidelines, folder structures, coding standards, and libraries (like reporting and data readers) that help teams write maintainable, scalable, and reusable automation code.

Common architectures include Data-Driven (data from Excel/JSON), Keyword-Driven, Behavior-Driven Development (BDD via Cucumber), and Hybrid frameworks combining POM with data-driven approaches.

POM is a design pattern where each screen of the mobile app is represented by a separate class. The class contains the UI locators and the actions performed on that screen, separating logic from tests.

You create Page classes for different screens. In Java, you often use `PageFactory` with `@AndroidFindBy` and `@iOSXCUITFindBy` annotations to define locators, and initialize them in the constructor using `AppiumFieldDecorator`.

TestNG and JUnit are unit testing frameworks for Java used to orchestrate test execution, group test cases, run tests in parallel, manage setup/teardown with annotations, and generate basic reports.

You run parallel tests by spinning up multiple Appium server instances on different ports and using TestNG parallel execution (via `testng.xml`), routing different devices using distinct `systemPort` (Android) or `wdaLocalPort` (iOS) capabilities.

You integrate by triggering Maven/Gradle commands from Jenkins or GitHub Actions. The pipeline checks out code, starts an emulator or connects to a cloud provider (BrowserStack/SauceLabs), runs the suite, and publishes reports.

Test data is abstracted out of test scripts and stored in external files like JSON, Excel (using Apache POI), or YAML, and read dynamically during execution to support Data-Driven Testing.

Teams usually integrate third-party reporting tools like ExtentReports or Allure Reports via TestNG listeners to generate rich HTML reports with embedded screenshots and execution logs.

Flakiness is handled by implementing robust explicit waits instead of thread sleeps, using dynamic locators, implementing a retry analyzer in TestNG to automatically re-run failures, and ensuring a clean app state before each test.

You can fetch the OTP by connecting to a backend database/API directly in the script, using third-party services like Twilio API to read SMS, or reading the OTP directly from the device's notification shade using Appium.

You open the device's notification shade (`driver.openNotifications()` on Android), locate the notification text, assert it, and click it to ensure the app handles the deep link correctly.

For upgrade testing, you use Appium to install the older APK via `driver.installApp()`, perform actions, and then install the newer APK over it to verify data migration and crash-free launches.

You can simulate network drops by toggling Airplane mode or Wifi programmatically using Appium's network connection commands (`driver.setConnection()`) on Android devices.

You use the `driver.rotate()` command to switch between PORTRAIT and LANDSCAPE orientations to ensure the UI scales correctly and app state is maintained.

You use `driver.runAppInBackground(Duration)` to put the app in the background for a specific time and verify its state and session remain intact when it resumes to the foreground.

Automating native camera UI is flaky. Instead, we use mock camera injection (provided by device clouds like BrowserStack) or push a test image to the device via ADB and automate the gallery picker to select it.

Common challenges include handling dynamic XPath performance issues, mitigating device fragmentation, managing flaky tests due to network speeds, configuring parallel execution routing, and automating complex gestures.

Execution time is reduced by running suites in parallel, avoiding slow XPaths, bypassing UI logins using API session injection, using cloud device farms, and minimizing the use of explicit thread sleeps.

I prioritize highly repetitive tests (regression suites), data-driven scenarios, critical business flows (login, checkout), and tests that take a long time to run manually. One-off edge cases or visual UX checks remain manual.