Unit 1: Mobile Testing Basics - Subjective Questions

Mobile application testing is the process of verifying and validating a mobile app to ensure that it works correctly, securely, efficiently, and consistently across supported devices and operating systems.

Major objectives include:

• Functional correctness: Verify that features, workflows, inputs, and outputs satisfy requirements.
• Compatibility: Ensure the app works across different devices, screen sizes, hardware configurations, and OS versions.
• Usability: Check navigation, readability, touch interactions, accessibility, and overall user experience.
• Performance: Measure startup time, response time, memory usage, CPU consumption, battery use, and network behavior.
• Security: Protect user data, authentication details, permissions, and network communication.
• Reliability: Confirm stable behavior during interruptions such as calls, notifications, low battery, and network changes.
• Installation testing: Validate installation, upgrade, uninstallation, and application-data retention behavior.

A successful mobile testing process combines manual testing, automated testing, real-device testing, and appropriate simulator or emulator testing.

Mobile testing is difficult because mobile environments are highly diverse and dynamic.

Major challenges are:

• Device fragmentation: Devices differ in manufacturer, processor, memory, sensors, resolution, and screen size.
• OS fragmentation: An app may need to support multiple Android or iOS versions and vendor-specific customizations.
• Network variability: Mobile apps operate under Wi-Fi, 4G, 5G, slow connections, packet loss, and offline conditions.
• Hardware differences: Cameras, GPS, biometric sensors, orientation sensors, and other hardware may behave differently.
• Interruptions: Calls, SMS messages, notifications, alarms, and background applications can interrupt app execution.
• Resource limitations: Battery, memory, storage, and CPU constraints can affect performance.
• Multiple app types: Native, hybrid, and mobile web apps require different testing approaches.
• Frequent releases: Short release cycles demand fast and maintainable automation.
• Permission and security behavior: Runtime permissions and privacy controls differ across OS versions.

These challenges make it necessary to use a risk-based device matrix, automation, cloud device farms, and testing under realistic conditions.

A comprehensive mobile testing strategy defines what will be tested, where it will be tested, and how quality will be measured.

Recommended strategy:

1. Analyze requirements: Identify business-critical workflows, supported platforms, user groups, and quality expectations.
2. Create a device matrix: Select devices according to market share, OS version, manufacturer, screen size, and hardware capability.
3. Choose test levels: Include unit, API, integration, UI, system, and acceptance testing.
4. Apply the test pyramid: Automate more unit and API tests, while keeping UI tests focused on critical end-to-end scenarios.
5. Combine test environments: Use emulators for fast feedback and real devices for final compatibility and hardware validation.
6. Cover non-functional areas: Test performance, accessibility, security, usability, battery usage, and network behavior.
7. Automate stable scenarios: Automate smoke, regression, and frequently repeated workflows with tools such as Appium.
8. Integrate with CI/CD: Execute tests for every important build and publish reports, logs, screenshots, and videos.
9. Maintain tests: Use stable locators, reusable page or screen objects, explicit waits, and independent test data.
10. Measure results: Track pass rate, defect leakage, execution time, device coverage, and flaky-test rate.

The strategy should balance execution speed, cost, device coverage, and confidence in the release.

Real devices, simulators, and emulators provide different levels of accuracy and execution speed.

Typical usage:

• Use emulators or simulators during development, debugging, and early automated regression.
• Use real devices for final validation, hardware features, performance, network behavior, and user-experience testing.
• A balanced strategy uses virtual devices for speed and real devices for confidence.

Real-device testing provides the closest representation of actual user conditions.

Advantages of real devices:

• Accurate touch, rendering, CPU, memory, and battery behavior.
• Real camera, GPS, biometric, Bluetooth, and sensor validation.
• Reliable evaluation of calls, notifications, network switching, and background behavior.
• Better assessment of usability and performance.

Limitations of real devices:

• Expensive to purchase, maintain, charge, and update.
• Difficult to cover a large number of device and OS combinations.
• Physical devices may require manual resetting and lab management.

Advantages of virtual devices:

• Quick creation of different OS, screen, and hardware profiles.
• Cost-effective and easy to integrate into development and CI pipelines.
• Support snapshots, clean states, debugging, and parallel execution.

Limitations of virtual devices:

• Do not perfectly reproduce battery, thermal, sensor, network, and performance behavior.
• Some hardware features are unavailable or simulated.
• Results can be influenced by the host computer.

Therefore, virtual devices are suitable for rapid feedback, while real devices are essential for release-level confidence.

Appium is an open-source automation framework used to test native, hybrid, and mobile web applications. It supports major mobile platforms and follows the WebDriver client-server model.

Important features:

• Supports Android and iOS automation through platform-specific drivers.
• Uses the W3C WebDriver protocol for client-server communication.
• Supports programming languages such as Java, Python, JavaScript, C#, and Ruby through client libraries.
• Can automate native, hybrid, and browser-based mobile applications.
• Allows testing on real devices, emulators, simulators, and cloud device platforms.
• Does not normally require application source-code modification or test-specific recompilation.
• Provides commands for element interaction, gestures, contexts, application lifecycle, and device operations.
• Integrates with test frameworks and CI/CD tools.

Benefits:

• A similar WebDriver-style API can be used across platforms.
• Existing language and testing-framework knowledge can be reused.
• Its driver and plugin architecture is extensible.
• It supports maintainable cross-platform automation when tests are designed with reusable abstractions.

Appium operates through a client-server architecture based on the W3C WebDriver protocol.

Main components:

• Test script: Written using an Appium client library in a language such as Java or Python.
• Appium client: Converts test operations into WebDriver-compatible HTTP commands.
• Appium server: Receives commands, validates capabilities, manages sessions, and routes requests.
• Platform driver: A driver such as UiAutomator2 or Espresso translates generic commands into platform-specific automation actions.
• Device automation framework: Executes actions on the application and returns results.

Command flow:

1. The test sends a new-session request with capabilities such as platform name, device name, and automation name.
2. The Appium server selects the required installed driver.
3. The driver establishes a session with the real or virtual device.
4. A test command, such as locating and tapping an element, is sent to the server.
5. The server forwards the command to the driver.
6. The driver uses the underlying platform automation technology to execute it.
7. The result is returned through the server to the client.
8. At the end, the client deletes the session and the server performs cleanup.

Thus, Appium separates test code from platform-specific implementation through a standard automation protocol.

Capabilities are key-value configuration options sent by the client when requesting an Appium session. They describe the target platform, device, application, and automation engine.

Common capabilities include:

• platformName: Identifies the platform, such as Android.
• appium:automationName: Selects a driver, such as UiAutomator2 or Espresso.
• appium:deviceName: Provides a logical device name.
• appium:udid: Identifies a specific connected device.
• appium:app: Specifies the path or URL of an application package.
• appium:appPackage and appium:appActivity: Identify an already installed Android application.
• appium:noReset: Controls whether application data is preserved between sessions.

Session creation process:

1. The client sends a W3C new-session request to the Appium server.
2. Appium validates standard and vendor-prefixed capabilities.
3. The server identifies the correct platform driver.
4. The driver prepares the device, optionally installs the application, and starts it.
5. A unique session identifier is returned to the client.
6. All later commands are associated with that session identifier.

In Appium 2, non-standard capabilities normally use the appium: vendor prefix. Correct capabilities are essential because invalid or conflicting values can prevent session creation.

Installation testing verifies that an application can be correctly deployed, updated, and removed under supported conditions.

Installation testing should verify:

• Installation from an application package, app store, enterprise source, or automation server.
• Behavior when storage is low or the package is invalid.
• Required permissions, application icon, version, and initial launch.
• First-run screens, default data, and configuration.

Upgrade testing should verify:

• Successful upgrade from supported earlier versions.
• Preservation or migration of user data, settings, sessions, and databases.
• Compatibility with changed permissions and schemas.
• Correct behavior after interrupted or failed updates.

Uninstallation testing should verify:

• Removal of the application and expected application data.
• Handling of files intentionally stored outside the private application area.
• Successful reinstallation after removal.

For Android command-line testing, adb install path-to-app.apk, adb install -r path-to-app.apk, and adb uninstall package.name can be used. Appium can also install the application during session creation through the appium:app capability or manage it with application lifecycle commands.

Mobile applications are commonly classified as native, mobile web, and hybrid applications.

Native applications

• Built for a particular platform using platform-supported technologies.
• Installed on the device as an application package.
• Can directly use device APIs such as camera, GPS, storage, and sensors.
• Testing must cover native controls, permissions, lifecycle behavior, gestures, and hardware integration.

Mobile web applications

• Websites accessed through a mobile browser.
• Usually do not require installation.
• Primarily use web technologies such as HTML, CSS, and JavaScript.
• Testing focuses on responsive layouts, browser compatibility, network behavior, cookies, and web-element interactions.

Hybrid applications

• Installed like native applications but contain one or more web views.
• Combine a native container with web content.
• Testing requires both native-element and web-element automation.
• Appium tests may need to switch between NATIVE_APP and a WEBVIEW context.

All three types require functional, usability, compatibility, and performance testing, but their element technologies, debugging tools, deployment methods, and automation contexts differ.

Appium tests can be executed through several environment configurations.

1. Local server with local emulator

• Appium and the emulator run on the developer's machine.
• Suitable for development, debugging, and quick feedback.

2. Local server with a USB-connected real device

• A physical device is connected to the test machine.
• Useful for hardware validation and realistic execution.

3. Local server with multiple devices

• Several devices or emulators are connected to one host.
• Parallel execution requires unique device identifiers and non-conflicting system ports.

4. Remote Appium server

• Tests run on one machine and send commands to an Appium server on another machine.
• Useful for centralized test laboratories.

5. Cloud device farm

• A provider supplies hosted real and virtual devices.
• Offers broad device coverage, parallel execution, logs, screenshots, and videos.

6. Containerized or CI-based setup

• Appium tests are started automatically by a CI/CD pipeline.
• Android emulators may run on suitable virtualized agents, while physical devices are often accessed through labs or cloud services.

The choice depends on budget, required device coverage, execution speed, security, scalability, and maintenance effort.

Both UiAutomator2 and Espresso are Appium drivers for Android, but they use different underlying automation approaches.

Selection guidance:

• Choose UiAutomator2 for broad Android automation, black-box testing, system UI interaction, and general compatibility.
• Choose Espresso when close app integration and synchronization are important and the application can support the required instrumentation setup.

The best driver depends on application architecture, required interactions, build access, stability needs, and environment constraints.

Appium 2 is a major redesign of the Appium server that separates the core server from platform drivers and optional plugins.

Important differences from Appium 1:

• Independent driver installation: Platform drivers are no longer automatically bundled with the core server.
• Driver management CLI: Commands such as appium driver install, appium driver list, and appium driver update manage drivers.
• Plugin architecture: Optional plugins can extend or modify server behavior.
• Extension management: Drivers and plugins can be installed and updated without reinstalling the core server.
• W3C capability format: Non-standard capabilities generally require a vendor prefix such as appium:.
• Default base path: Appium 2 commonly uses / as the default base path, while older configurations often used /wd/hub.
• Modular maintenance: Platform-specific projects can release updates independently from the server.
• Configuration flexibility: Server arguments, configuration files, environment variables, and extension commands support customized setups.

The modular design reduces unnecessary dependencies and makes Appium easier to extend, but users must explicitly install the drivers needed for their target platforms.

A typical Appium 2 installation requires Node.js, npm, the Appium server, and at least one platform driver.

Procedure:

1. Install Node.js and npm: Use a supported Node.js release and verify with node --version and npm --version.
2. Install Appium globally: Run npm install -g appium.
3. Verify Appium: Run appium --version.
4. List available or installed drivers: Run appium driver list.
5. Install an Android driver: Run appium driver install uiautomator2.
6. Optionally install Espresso: Run appium driver install espresso if it is required by the project.
7. Check installed drivers: Run appium driver list --installed.
8. Start the server: Run appium and confirm that the server starts without errors.
9. Prepare the platform SDK: Configure Java, Android SDK tools, environment variables, and a real or virtual device.
10. Validate device connectivity: Run adb devices and confirm that the target appears as authorized.
11. Create a test session: Send appropriate W3C capabilities through an Appium client or an inspector tool.
12. Review logs: Confirm successful driver loading, application installation or launch, and session creation.

Installation is complete only when the server, platform driver, SDK, device, and client can create and terminate a real test session successfully.

The Java Development Kit is required by Android build tools and several components used in Android automation.

Setup steps:

1. Download and install a JDK version compatible with the Android and automation toolchain.
2. Locate the JDK installation directory.
3. Create the JAVA_HOME environment variable and set it to the JDK directory, not the bin subdirectory.
4. Add the JDK executable directory to the system PATH, commonly as JAVA_HOME/bin through the operating system's variable syntax.
5. Open a new terminal so that updated variables are loaded.
6. Run java -version to verify the Java runtime.
7. Run javac -version to verify the Java compiler.
8. If multiple JDKs are installed, ensure that JAVA_HOME and the first relevant Java entry in PATH refer to the intended version.

Common configuration problems:

• JAVA_HOME points to a JRE rather than a JDK.
• The variable points directly to the bin directory.
• An older Java executable appears earlier in PATH.
• The terminal or IDE was not restarted after variable changes.

Correct JDK configuration enables Android SDK tools, Gradle, drivers, and test projects to locate Java consistently.

Android Studio provides the Android SDK, SDK Manager, emulator tools, and device-management utilities needed for Android automation.

Configuration procedure:

1. Install Android Studio for the host operating system.
2. Complete the setup wizard and install the recommended Android SDK components.
3. Open SDK Manager and install:
   • A required Android SDK Platform.
   • Android SDK Platform-Tools.
   • Android SDK Build-Tools.
   • Android Emulator.
   • Relevant command-line tools and system images.
4. Note the Android SDK location shown in Android Studio.
5. Configure an SDK environment variable, commonly ANDROID_HOME or ANDROID_SDK_ROOT, according to the toolchain requirements.
6. Add important SDK directories, especially platform-tools, to PATH so that adb is available.
7. Open Device Manager and create an Android Virtual Device with a suitable system image.
8. Start the emulator and wait for Android to finish booting.
9. Run adb devices and verify that the emulator appears.
10. Install the Appium Android driver and create a session using matching platform and device capabilities.

A correct setup is confirmed when SDK tools run from the terminal, the device is visible to ADB, and Appium can launch or install an application.

Both targets must be visible through the Android Debug Bridge before Appium can automate them.

Preparing a real Android device

• Enable Developer options by tapping the build number as required by the device.
• Enable USB debugging.
• Connect the device using a reliable data cable.
• Install the appropriate host USB driver when required.
• Accept the RSA authorization prompt displayed on the device.
• Run adb devices and confirm that the state is device, not unauthorized or offline.
• Keep the device unlocked and configure permissions needed by the test.
• Use the device identifier as appium:udid when multiple devices are connected.

Preparing an emulator

• Install Android Emulator and a system image through Android Studio.
• Create an Android Virtual Device with the required API level and screen profile.
• Enable host virtualization or hardware acceleration.
• Start the emulator and wait until boot completion.
• Run adb devices to obtain the emulator identifier.
• Install or launch the application through Appium.

In both cases, the chosen API level must be supported by the application and Appium driver. Stable automation also requires sufficient storage, a predictable device state, and non-conflicting ports during parallel execution.

Important official resources help engineers install Appium, select drivers, understand commands, and diagnose issues.

• Appium documentation: https://appium.io/docs/
  • Provides installation instructions, server concepts, capabilities, commands, drivers, plugins, and migration guidance.
• Appium GitHub organization: https://github.com/appium
  • Hosts the server, drivers, clients, examples, issue trackers, and source code.
• Appium server repository: https://github.com/appium/appium
  • Useful for release notes, server issues, contribution information, and implementation details.
• Appium npm package: https://www.npmjs.com/package/appium
  • Shows package information, published versions, and npm installation details.
• UiAutomator2 driver repository: https://github.com/appium/appium-uiautomator2-driver
  • Documents Android capabilities, requirements, supported commands, and driver-specific issues.
• Espresso driver repository: https://github.com/appium/appium-espresso-driver
  • Explains Espresso setup, limitations, capabilities, and troubleshooting.
• Appium Discuss forum: https://discuss.appium.io/
  • Provides community discussions and solutions to practical automation problems.

Engineers should prefer current official documentation and driver-specific repositories because behavior and requirements may change between releases.

Appium setup failures commonly result from missing dependencies, incorrect environment variables, invalid capabilities, or device connectivity issues.

Common problems and solutions:

• Appium command not found: Verify the npm global installation and ensure the npm global executable directory is in PATH.
• Driver not found: Run appium driver list --installed and install the required driver.
• ADB command not found: Add the Android SDK platform-tools directory to PATH.
• Device unauthorized: Reconnect the device, accept the RSA prompt, and restart ADB if necessary.
• Device offline: Restart the device or emulator and run adb kill-server followed by adb start-server.
• No matching device: Verify appium:udid, platform version, and the output of adb devices.
• Application does not launch: Check the application path, package name, activity name, and application compatibility.
• Capability validation error: Use correct W3C capabilities and the appium: prefix for Appium-specific options.
• Connection to /wd/hub fails: Confirm the server base path because Appium 2 commonly defaults to /.
• Java or SDK error: Validate JAVA_HOME, Android SDK variables, installed SDK packages, and command-line tool versions.

Troubleshooting should begin with server logs, driver logs, the exact session payload, tool versions, and a minimal test session.

An end-to-end setup must connect the development tools, Appium components, target device, application, and test framework.

Workflow:

1. Install prerequisites: Install a compatible JDK, Node.js, npm, and Android Studio.
2. Configure Java: Set JAVA_HOME, update PATH, and verify java -version and javac -version.
3. Configure Android SDK: Install platform tools, build tools, emulator components, and at least one SDK platform.
4. Set SDK variables: Configure the SDK environment variable and add platform-tools to PATH.
5. Prepare a target: Start an emulator or connect an authorized real device.
6. Validate ADB: Run adb devices and record the target's identifier.
7. Install Appium 2: Run npm install -g appium and verify the version.
8. Install a driver: Run appium driver install uiautomator2.
9. Start Appium: Launch the server and note its host, port, and base path.
10. Prepare the application: Obtain the APK or identify the package and launchable activity of an installed app.
11. Configure capabilities: Provide platformName, appium:automationName, device identifier, and application details.
12. Create a test project: Add the appropriate Appium client and a unit-testing framework.
13. Implement a smoke test: Create a session, locate elements using stable selectors, perform actions, verify an expected result, and quit the driver.
14. Collect diagnostics: Preserve server logs, test reports, screenshots, and page source for failures.
15. Integrate with CI/CD: Parameterize device settings and execute the smoke or regression suite on each selected build.

The workflow is successful when a repeatable test can install or launch the app, execute a user scenario, report the result, and cleanly terminate the session.