Unit 1: Mobile Testing Basics

I. Orientation: Foundations of Mobile Automated Testing

Mobile automated testing uses software tools to execute tests against mobile applications, control user-interface elements, and compare actual behavior with expected results. Its governing principle is that automation must account for the application, operating system, device hardware, network, and automation driver as one connected test environment.

• Purpose: Verify functional behavior, compatibility, reliability, usability, performance, security, and installation across supported mobile configurations.
• Test target: An Android package normally uses an .apk or .aab; an iOS application uses an .app bundle or .ipa.
• Automation boundary: UI automation reproduces actions such as tapping, typing, swiping, and reading element attributes, while unit and API tests cover lower layers.
• Platform conventions:
  • Android applications are commonly identified by appPackage and appActivity.
  • iOS applications are commonly identified by bundleId.
• Core requirement: A repeatable test needs a known app build, device state, OS version, driver version, permissions configuration, and test-data state.
• Good automation target: Stable, repetitive, business-critical workflows such as login, checkout, form validation, and regression testing provide the greatest value.

II. Mobile Testing Environment — Risks, Strategy, and Execution Targets

A. Mobile Testing Challenges

Mobile testing is difficult because application behavior varies across devices, operating systems, hardware capabilities, and changing environmental conditions.

• Device fragmentation: Android devices differ in screen size, resolution, chipset, memory, manufacturer customization, and API level; a layout that works at 1080 × 2400 may fail at 720 × 1600.
• Operating-system variation: Permissions, notifications, background execution, and UI behavior can change between Android API levels or iOS releases.
• Network variability: Tests must consider Wi-Fi, cellular connections, latency, packet loss, offline operation, and transitions between networks.
• Hardware dependence: Cameras, GPS, biometrics, Bluetooth, NFC, orientation sensors, and batteries cannot always be represented accurately by virtual devices.
• Interruptions: Calls, notifications, permission dialogs, low-battery warnings, and app backgrounding can disrupt a workflow.
• Automation instability: Dynamic identifiers, animations, delayed rendering, and asynchronous API calls can cause flaky tests; explicit waits should replace fixed delays such as sleep(5000).
• Resource constraints: Limited CPU, memory, storage, and battery can expose defects that do not appear on development computers.

B. Mobile Testing Strategy

A mobile testing strategy defines what will be tested, at which layer, on which configurations, and with what level of automation.

• Risk analysis: Prioritize revenue-critical flows, frequently used features, security-sensitive operations, and areas with a history of defects.
• Test pyramid: Use many fast unit tests, fewer API or integration tests, and a focused set of slower UI tests.
• Coverage matrix: Select combinations of OS version, manufacturer, screen size, locale, network, and app version according to actual user data.
• Automation selection: Automate deterministic regression scenarios; retain exploratory testing for usability, visual quality, and unexpected interactions.
• Execution stages:
  1. Run unit and API tests on every commit.
  2. Run smoke UI tests on virtual devices during continuous integration.
  3. Run broader regression tests on representative real devices before release.
• Stability controls: Reset test data, use unique accounts, wait for observable conditions, capture screenshots and logs, and isolate tests from execution order.

C. Real Devices

Real devices are physical phones or tablets used to validate behavior under authentic hardware and operating conditions.

• Advantages: They provide accurate performance, battery, thermal, camera, GPS, biometric, cellular, and manufacturer-specific behavior.
• Limitations: Purchasing, charging, updating, connecting, and reserving many devices creates cost and maintenance overhead.
• Connections: Android devices commonly connect through Android Debug Bridge; adb devices lists recognized devices.
• Recommended use: Use real devices for final compatibility checks, hardware-dependent functionality, performance validation, and release acceptance.
• Remote access: Device-cloud services provide physical devices through web interfaces and automation endpoints, reducing local laboratory maintenance.

D. Simulators and Emulators

Simulators and emulators provide software-based mobile environments for rapid development and automated execution.

1. Simulator: Models an operating environment without fully reproducing the target hardware; Apple’s iOS Simulator runs applications compiled specifically for the simulator architecture.
2. Emulator: Reproduces hardware and operating-system behavior more completely; the Android Emulator runs Android Virtual Devices, or AVDs.

• Advantages: Virtual devices are inexpensive, reproducible, easy to reset, and practical for parallel CI execution.
• Limitations: Sensors, battery behavior, cellular networking, graphics performance, and manufacturer modifications may differ from physical devices.
• Best balance: Use virtual devices for fast development and routine regression, then confirm important flows on real hardware.

III. Mobile Applications and Appium — Application Models and Automation Architecture

A. Types of Mobile Apps

Mobile applications are classified by how they are built, distributed, rendered, and integrated with the device.

• Native apps: Built for one platform using technologies such as Kotlin/Java for Android or Swift/Objective-C for iOS; they expose native UI elements to platform automation frameworks.
• Mobile web apps: Websites opened in browsers such as Chrome or Safari; Appium generally automates them through a browser context and WebDriver-compatible driver.
• Hybrid apps: Native containers that embed web content through components such as Android WebView; tests may switch between NATIVE_APP and WEBVIEW contexts.
• Cross-platform apps: Frameworks such as Flutter or React Native share code across platforms, although the resulting automation behavior depends on how controls are rendered and exposed.

B. Mobile App Installation

Installation places a compatible application build on a target device and prepares it for testing.

• Android installation: An APK can be installed with:
  
  BASH

    adb install -r path/to/app.apk

  
  The -r option reinstalls the package while retaining existing application data where permitted.
• Appium installation behavior: The appium:app capability can specify a local path or accessible URL; the driver installs the build when the session begins.
• Existing application: appium:appPackage and appium:appActivity can launch an installed Android app without supplying its build.
• State control: appium:noReset=true preserves app data; appium:fullReset=true may uninstall and reinstall the app, depending on driver behavior.
• Signing: Android and iOS builds must be signed appropriately; physical iOS devices additionally require valid provisioning and trusted developer configuration.

C. What is Appium?

Appium is an open-source automation server that implements the WebDriver protocol for native, hybrid, and mobile-web applications.

• Client-server model: Test code sends WebDriver commands to an Appium server rather than controlling the device directly.
• Language flexibility: Clients are available for Java, JavaScript, Python, C#, Ruby, and other languages supporting WebDriver-style requests.
• Platform integration: Appium delegates commands to platform-specific drivers such as UiAutomator2, Espresso, or XCUITest.
• Application neutrality: Production app code usually does not require Appium-specific instrumentation, although the selected driver may impose build or signing requirements.
• Typical command: A test locating an element by accessibility identifier sends a findElement request, after which the driver queries the platform automation framework.

D. How Appium works? Architecture Overview

Appium translates standardized client commands into platform-specific automation operations and returns structured responses.

• Test client: A language binding creates a session using capabilities such as platformName, appium:automationName, and appium:deviceName.
• Appium server: The Node.js process receives HTTP requests, validates routes, manages sessions, and forwards commands.
• Driver: The installed platform driver converts WebDriver commands into calls understood by UiAutomator2, Espresso, or XCUITest.
• Device-side component: A helper server or instrumentation process interacts with the application and operating system.
• Response path: Element data, status, or an error travels from the device through the driver and server to the client.

Test Code -> Appium Client -> Appium Server -> Driver
          -> Device Automation Framework -> Application

• Capabilities example:
  
  JSON

    {
      "platformName": "Android",
      "appium:automationName": "UiAutomator2",
      "appium:deviceName": "emulator-5554",
      "appium:app": "/apps/demo.apk"
    }

  
  Appium-specific capabilities use the appium: vendor prefix.

IV. Appium Configuration — Deployment Choices, Drivers, and Resources

A. Setup Possibilities

An Appium environment can be arranged locally, remotely, or as part of a scalable automated pipeline.

• Local setup: The Appium server, SDK, emulator, and tests run on one workstation; this is simple for learning and debugging.
• Separated setup: Tests run on one machine while Appium runs on a remote host connected to devices.
• Grid or cloud setup: Multiple servers or a device-cloud provider execute tests concurrently across device configurations.
• Desktop inspection: Appium Inspector can create sessions, display the UI hierarchy, examine attributes, and test locator strategies.
• CI setup: A pipeline starts an emulator or reserves a device, launches Appium, executes tests, and preserves logs, screenshots, and reports as artifacts.

B. UiAutomator2 Vs Espresso Driver

UiAutomator2 and Espresso are Android automation drivers with different execution models and suitable use cases.

1. UiAutomator2 driver:
   • Automates the app and Android system UI from outside the application process.
   • Supports native, hybrid, and mobile-browser testing.
   • Handles cross-app workflows and permission dialogs effectively.
   • Is the general-purpose choice for black-box Android testing.
2. Espresso driver:
   • Uses Google’s Espresso instrumentation within the application testing environment.
   • Benefits from synchronization with the app’s UI thread and can execute app-focused interactions quickly.
   • May require access to a compatible application build and is less suitable for extensive cross-app or system-UI workflows.

• Selection rule: Choose UiAutomator2 for broad end-to-end compatibility; choose Espresso when close Android-app integration and synchronization justify its additional constraints.

C. Important Appium links

The official Appium resources provide installation instructions, driver documentation, API guidance, and maintained source code.

• Documentation: https://appium.io/docs/en/latest/
• Appium repository: https://github.com/appium/appium
• UiAutomator2 driver: https://github.com/appium/appium-uiautomator2-driver
• Espresso driver: https://github.com/appium/appium-espresso-driver
• XCUITest driver: https://github.com/appium/appium-xcuitest-driver
• Appium Inspector: https://github.com/appium/appium-inspector
• Extension discovery: appium driver list displays available or installed drivers from the command line.

V. Appium 2.0 Toolchain — Server and Android Development Setup

A. Appium 2.0 Overview and the Installation

Appium 2 separates the core server from platform drivers and plugins, allowing extensions to be installed and updated independently.

• Modular design: Installing Appium does not automatically install UiAutomator2, Espresso, or XCUITest.
• Extension CLI: Drivers are managed through commands such as appium driver install, list, update, and uninstall.
• Capability format: Non-standard capabilities require a vendor prefix, for example appium:automationName.
• Server route: The default base path is /; clients requiring the older /wd/hub path need matching server configuration.
• Configuration location: Appium extension data is stored under APPIUM_HOME, which defaults to the user’s .appium directory.

B. Installing Appium 2.0 server

The Appium 2 server is installed through npm after a compatible Node.js and npm environment is available.

• Installation:
  
  BASH

    npm install --global appium@2
    appium --version

• Android driver:
  
  BASH

    appium driver install uiautomator2
    appium driver list --installed

• Validation:
  
  BASH

    appium driver doctor uiautomator2

• Startup:
  
  BASH

    appium

  
  The server normally listens on port 4723; logs show session creation, command routing, and driver errors.
• Version control: CI environments should pin tested Appium and driver versions instead of silently accepting incompatible upgrades.

C. Setup JAVA JDK

A Java Development Kit is required by Android build tools, ADB-related workflows, and Android automation drivers.

• Installation: Install a supported 64-bit JDK, commonly JDK 17 for modern Android toolchains.
• Environment variable: Set JAVA_HOME to the JDK directory and add its bin directory to PATH.
  
  BASH

    export JAVA_HOME=/path/to/jdk-17
    export PATH="$JAVA_HOME/bin:$PATH"
    java -version
    javac -version

• Verification: java and javac should report compatible versions and resolve from the intended JDK installation.
• Consistency: Android Studio, Gradle, terminal sessions, and CI agents should use compatible Java versions to prevent build or instrumentation failures.

D. Setup Android Studio

Android Studio supplies the Android SDK, platform tools, emulator, build tools, and virtual-device management needed for Android testing.

• SDK components: Install an Android SDK Platform, SDK Build-Tools, Android SDK Platform-Tools, Android Emulator, and an appropriate system image.
• Environment variables: Set ANDROID_HOME or ANDROID_SDK_ROOT to the SDK directory and add platform tools to PATH.
  
  BASH

    export ANDROID_HOME="$HOME/Android/Sdk"
    export PATH="$PATH:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator"

• Virtual device: Use Device Manager to create an AVD with a chosen API level, hardware profile, memory allocation, and system image.
• Verification:
  
  BASH

    adb version
    adb devices
    emulator -list-avds

• Device preparation: Enable Developer Options and USB debugging on physical Android devices, authorize the computer, and confirm that adb devices reports the target as device, not unauthorized or offline.