Appium Part 1

 For a 6-year Appium/SDET interview, don't prepare only definition-based questions. Expect the interviewer to ask architecture + troubleshooting + framework + real-project scenarios.

Below is a focused Level 1 interview set for Appium 3, with Appium 1/2/3 comparison where relevant.


1. Appium Architecture

Q1. Explain Appium architecture.

Answer:

Appium follows a client-server architecture. My Java test communicates with the Appium server through the Appium Java Client using the W3C WebDriver protocol. Appium then routes the commands to the appropriate platform driver, such as UiAutomator2 for Android or XCUITest for iOS. The driver communicates with the mobile platform and performs the requested action.

For Android:

Java + Cucumber/TestNG
        ↓
Appium Java Client
        ↓
W3C WebDriver
        ↓
Appium 3 Server
        ↓
UiAutomator2 Driver
        ↓
ADB / Android automation
        ↓
Android Emulator / Real Device
        ↓
Application

Q2. What happens internally when you execute this?

driver.findElement(AppiumBy.id("login")).click();

Answer:

The Java client sends a W3C WebDriver command to the Appium server. Appium routes the command to the UiAutomator2 driver. The driver communicates with the Android automation layer, finds the element and performs the click on the device.


Q3. What is the role of Appium Server?

Answer:

Appium Server receives commands from the client, manages the automation session and routes commands to the appropriate platform driver. In Appium 2 and 3, the server is separated from the platform-specific drivers.


Q4. What is the role of the Appium driver?

Answer:

The driver implements platform-specific automation. For Android I use UiAutomator2, and for iOS I use XCUITest.


Q5. What happens if the Appium server is running but UiAutomator2 is not installed?

Answer:

The server can start, but Appium cannot create an Android UiAutomator2 session. I would verify the installed drivers using:

appium driver list

and install it if required:

appium driver install uiautomator2

2. Appium 1 vs 2 vs 3

Q6. What is the biggest difference between Appium 1, 2 and 3?

Answer:

Appium 1 was more monolithic. Appium 2 introduced a modular architecture where drivers and plugins are installed separately. Appium 3 retains the Appium 2 architecture but removes additional deprecated/legacy APIs, raises runtime requirements and tightens some server behavior.


Q7. What changed from Appium 1 to Appium 2?

Answer:

The important changes are:

Appium 1
   ↓
Monolithic
   ↓
Appium 2
   ├── Core server
   ├── Drivers
   └── Plugins

Major changes:

  • Drivers installed separately

  • Plugins installed separately

  • W3C WebDriver approach

  • /wd/hub no longer default

  • appium: prefix for Appium-specific capabilities

  • JSONWP/MJSONWP removed

  • More modular architecture


Q8. What changed from Appium 2 to Appium 3?

Answer:

Appium 3 is primarily a cleanup and modernization release. It keeps the modular architecture but removes more deprecated endpoints and legacy parameter handling, raises the Node.js requirement and requires explicit scoping for insecure server features.


Q9. Is Appium 3 completely different from Appium 2?

Answer:

No.

This is an important interview point.

Your normal code remains familiar:

driver.findElement(...).click();
driver.findElement(...).sendKeys("test");
driver.getPageSource();
driver.quit();

The major changes are around:

Server
Drivers
Deprecated endpoints
Capabilities
Security configuration
Session discovery
Node.js requirements

Q10. Is /wd/hub required in Appium 3?

Answer:

No.

The default Appium 2/3 server URL is:

http://127.0.0.1:4723

/wd/hub is a legacy path.

If backward compatibility is required, the server can be configured with an appropriate base path.


3. Appium 3 Installation

Q11. How do you install Appium 3?

Answer:

First verify Node:

node --version
npm --version

Then:

npm install -g appium

Verify:

appium --version

Then install Android driver:

appium driver install uiautomator2

Verify:

appium driver list

Start:

appium

Q12. How do you verify that Appium 3 is correctly configured?

I check:

node --version
npm --version
appium --version
appium driver list
adb devices

Then start:

appium

Finally, I create an Appium session from my Java test.


Q13. What if Appium starts but the Android session fails?

I check in this order:

Node/npm
   ↓
Appium version
   ↓
UiAutomator2 installed?
   ↓
ADB available?
   ↓
Device connected?
   ↓
Device online?
   ↓
Appium server running?
   ↓
Capabilities
   ↓
appPackage/appActivity
   ↓
Appium logs

4. UiAutomator2

Q14. What is UiAutomator2?

Answer:

UiAutomator2 is the Android automation driver used by Appium. It allows Appium to interact with Android applications and UI elements.

Capability:

options.setAutomationName("UiAutomator2");

Q15. Why do you use UiAutomator2 instead of UiAutomator?

Answer:

UiAutomator2 is the current Android automation driver I would use with Appium 2/3. It provides modern Android automation capabilities and supports native, hybrid and mobile web automation scenarios.


Q16. How do you install UiAutomator2?

appium driver install uiautomator2

Verify:

appium driver list

Q17. What capabilities do you use for Android?

Example:

UiAutomator2Options options = new UiAutomator2Options();

options.setPlatformName("Android");
options.setAutomationName("UiAutomator2");
options.setDeviceName("VT11");
options.setAppPackage("com.duracell");
options.setAppActivity("MainActivity");

Then:

AndroidDriver driver =
    new AndroidDriver(
        new URL("http://127.0.0.1:4723"),
        options
    );

Q18. What is the difference between appPackage and appActivity?

Answer:

appPackage identifies the Android application.

com.duracell

appActivity identifies the Android activity that needs to be launched.

MainActivity

Together they help Appium launch the application.


Q19. How do you find package and activity?

Useful ADB commands:

adb shell pm list packages

For the current activity/window information, I can use:

adb shell dumpsys window

or inspect the application/device logs.


5. XCUITest

Q20. What is XCUITest?

Answer:

XCUITest is Apple's UI testing framework and the Appium XCUITest driver uses Apple's XCTest/WebDriverAgent infrastructure to automate iOS applications.

Architecture:

Java Test
   ↓
Appium 3
   ↓
XCUITest Driver
   ↓
WebDriverAgent
   ↓
iOS

Q21. What capability do you use for iOS?

platformName = iOS
automationName = XCUITest

For example:

XCUITestOptions options =
        new XCUITestOptions();

options.setPlatformName("iOS");
options.setAutomationName("XCUITest");
options.setDeviceName("iPhone");

Q22. Can you run XCUITest/Appium iOS automation directly from Windows?

Answer:

The iOS XCUITest stack depends on Apple's Xcode/macOS environment. Therefore, for iOS automation from a Windows development machine, I would use a remote Mac or a cloud/device-farm environment that provides macOS and iOS devices.


Q23. Android vs iOS automation architecture?

AndroidiOS
UiAutomator2XCUITest
ADBXcode/WebDriverAgent
Android EmulatoriOS Simulator
Android real deviceiPhone/iPad
appPackageBundle ID

6. ADB

Q24. What is ADB?

Answer:

ADB stands for Android Debug Bridge. It is a command-line tool that allows communication between the development machine and Android devices or emulators.


Q25. What ADB commands do you commonly use?

adb devices

Check devices.

adb shell

Open device shell.

adb install app.apk

Install APK.

adb uninstall com.example.app

Uninstall application.

adb shell pm list packages

List packages.

adb logcat

View Android logs.


Q26. What if adb devices shows offline?

Answer:

I would troubleshoot:

adb kill-server
adb start-server
adb devices

If it remains offline:

  • Reconnect device

  • Restart emulator

  • Check USB debugging

  • Accept RSA authorization

  • Check USB/network connection

  • Check ADB version/path

  • Verify there isn't another conflicting ADB installation


Q27. What if no device is shown?

I check:

ADB installed?
       ↓
ANDROID_HOME / SDK configured?
       ↓
adb command available?
       ↓
Device/emulator running?
       ↓
USB debugging?
       ↓
adb devices

7. Capabilities

Q28. What are capabilities?

Answer:

Capabilities tell Appium what platform, automation engine, device and application I want to automate when creating a session.

Example:

{
  "platformName": "Android",
  "appium:automationName": "UiAutomator2",
  "appium:deviceName": "VT11",
  "appium:appPackage": "com.duracell",
  "appium:appActivity": "MainActivity"
}

Q29. Why do we use appium: prefix?

Answer:

platformName is a standard W3C capability. Appium-specific capabilities use the vendor prefix appium: to comply with the W3C WebDriver capability model.

With UiAutomator2Options, the Java client handles the appropriate capability representation.


Q30. What is noReset?

It controls whether the application state should be preserved between sessions.

Conceptually:

noReset = true

means don't automatically reset application state.

noReset = false

allows the driver to reset more application state depending on the driver/application setup.


Q31. What is fullReset?

Answer:

fullReset is a stronger reset behavior that can involve uninstalling/reinstalling the application. I use it carefully because it can significantly increase execution time and remove application state.


Q32. What is autoGrantPermissions?

For Android:

options.setAutoGrantPermissions(true);

It allows supported runtime permissions to be automatically granted during app setup.


8. Appium Inspector

Q33. What is Appium Inspector?

Answer:

Appium Inspector is a UI inspection tool that allows me to inspect the mobile application's UI hierarchy and identify attributes such as resource ID, accessibility ID, class name, text and XPath.


Q34. How do you identify a good locator?

I look for:

Accessibility ID
       ↓
Resource ID
       ↓
Stable unique attribute
       ↓
Class name
       ↓
UiAutomator
       ↓
XPath

I prefer stable and unique attributes over complex XPath.


Q35. Why do you avoid XPath when possible?

Answer:

XPath can become fragile when the UI hierarchy changes. It can also be less efficient than stable IDs or accessibility identifiers. Therefore, I prefer stable IDs or accessibility IDs whenever they are available.


9. Locators — 6-Year-Level Questions

Q36. An element has no ID and no accessibility ID. How will you locate it?

I would inspect the UI hierarchy and consider:

resource-id
text
content-desc
class
UiSelector
XPath

For Android, I may use:

driver.findElement(
    AppiumBy.androidUIAutomator(
        "new UiSelector().text(\"Login\")"
    )
);

Q37. How do you handle dynamic XPath?

Instead of:

//android.widget.TextView[@text='Welcome Sunil']

I might use:

//android.widget.TextView[contains(@text,'Welcome')]

But I would first look for a stable ID/accessibility identifier.


Q38. What if multiple elements have the same locator?

I don't simply use:

findElement()

and hope for the correct element.

I would inspect the hierarchy and identify a unique parent-child relationship or another stable attribute.

For example:

//android.widget.LinearLayout[@resource-id='...']
    //android.widget.TextView[@text='Login']

Q39. Your XPath works today but fails after a UI release. How do you debug it?

My process:

Failure
 ↓
Open Appium Inspector
 ↓
Compare old/new UI hierarchy
 ↓
Check locator
 ↓
Check screen/state
 ↓
Check synchronization
 ↓
Replace fragile locator
 ↓
Re-run affected tests

I would avoid simply adding Thread.sleep().


Q40. What is the difference between ID and Accessibility ID?

Answer:

ID generally refers to a platform-specific resource identifier, while Accessibility ID maps to the element's accessibility identifier/content description depending on the platform. Accessibility IDs are particularly useful because they can provide stable, semantic locators and also support accessibility.


10. Senior-Level Scenario Questions

These are the questions I'd expect after the interviewer sees 6 years of automation experience.

Q41. Your Appium session takes 2 minutes to start. How do you investigate?

I would check:

Appium server startup
       ↓
Device connection
       ↓
ADB
       ↓
UiAutomator2 server installation/startup
       ↓
APK installation
       ↓
Application launch
       ↓
Capabilities
       ↓
Appium logs

Then determine exactly which step consumes the time rather than blindly increasing timeout values.


Q42. 1000 tests are executed and 400 fail. What do you do?

I would classify failures:

Device/session failures
Application crashes
Element failures
Synchronization failures
Network failures
Assertion failures

Then group failures by common error messages.

For example:

150 → Device unavailable
100 → Session creation
80  → Element not found
40  → Timeout
20  → App crash
10  → Assertion

This helps determine whether the primary problem is infrastructure, automation or application behavior.


Q43. Tests pass locally but fail in Jenkins. What do you check?

I check:

  • Java version

  • Node version

  • Appium version

  • Appium driver version

  • Android SDK

  • ADB path

  • Device availability

  • Environment variables

  • App path

  • Permissions

  • Network

  • Appium server logs

  • Jenkins workspace

  • Parallel execution conflicts


Q44. Tests pass individually but fail when executed in parallel. Why?

Possible reasons:

Shared driver
Shared device
Shared test data
Same port
Same app state
Same account
Same files
Thread-safety problems

For multiple devices, I would use a properly isolated driver/session per test thread/device and ensure unique ports/resources where required.


Q45. How would you make an Appium framework maintainable?

My approach:

Driver Factory
      ↓
Page Object Model
      ↓
Reusable utilities
      ↓
Explicit waits
      ↓
Configuration management
      ↓
Test data management
      ↓
Logging
      ↓
Screenshot on failure
      ↓
Extent/other reporting
      ↓
Cucumber/TestNG
      ↓
Jenkins CI/CD

⭐ Questions you should be able to answer without hesitation

For a 6-year Appium/SDET interview, I would especially memorize and practice these:

  1. Explain Appium architecture end-to-end.

  2. Explain Appium 1 vs 2 vs 3.

  3. Why was Appium 2 introduced?

  4. What changed in Appium 3?

  5. How do you install and configure Appium 3?

  6. What is UiAutomator2?

  7. What happens internally when click() is executed?

  8. What is ADB and which commands do you use?

  9. ADB shows offline — how do you troubleshoot?

  10. Explain W3C capabilities.

  11. Why is appium: required?

  12. What are appPackage and appActivity?

  13. How do you inspect elements?

  14. Which locator do you prefer and why?

  15. How do you handle dynamic locators?

  16. How do you debug NoSuchElementException?

  17. Explain Android vs iOS Appium architecture.

  18. What is XCUITest/WebDriverAgent?

  19. How do you execute iOS automation from a Windows environment?

  20. 1000 tests run and 400 fail — how do you investigate?

  21. Tests pass locally but fail in Jenkins — how do you debug?

  22. Tests pass individually but fail in parallel — why?

  23. How do you design an Appium framework?

  24. How do you reduce flaky Appium tests?

  25. How do you decide whether a failure is an application defect or automation/infrastructure defect?

For 6 years of experience, your answers should generally follow this pattern:

Concept → how you implemented it → problem you faced → how you debugged it → solution.

That will sound much stronger than giving only textbook definitions.

Comments