A4Q Foundation Level Tester for Appium key terms

An open-source automation framework that drives native, hybrid, and mobile web applications on Android and iOS using the WebDriver protocol, without requiring the app under test to be recompiled or modified.

A language-neutral HTTP-based contract in which a client sends JSON commands to a server that controls a browser or device, returning responses that describe the outcome of each automation command.

A language-specific library such as Java, Python, or JavaScript that translates test code into WebDriver protocol requests and sends them to the Appium server for execution on a device.

The Node.js process that receives WebDriver requests from clients, routes them to the correct platform driver, and manages sessions, device communication, and command responses.

A platform-specific component, such as UiAutomator2 for Android or XCUITest for iOS, that translates generic WebDriver commands into actions the underlying automation framework on the device can perform.

A bounded automation conversation between client and server that is created with desired capabilities, targets one device and app, and must be ended to release resources and avoid port conflicts.

A JSON object of key-value pairs sent when creating a session that tells the server which platform, device, app, and automation engine the test requires.

A single named setting within desired capabilities, such as platformName or appPackage, that constrains or configures how a session is created and behaves.

A client-side object in newer Appium clients that collects capabilities in a typed way before session creation, replacing ad-hoc maps and reducing typos in capability names.

An app built with platform-specific toolkits and installed as a package, using native UI controls that Appium automates through the platform's own automation framework.

An app that wraps web content in a native container, mixing native screens with embedded web views, so tests must switch context between native and web automation modes.

A website accessed through a mobile browser rather than installed as a package, automated by Appium by launching the browser and interacting with page elements.

The current automation mode of a session, either native or a named web view, which determines whether elements are located through native or web element lookup.

Changing a session's active context between native and web view so that element finding and interaction target the correct layer of a hybrid application.

An embedded browser component inside a native app that renders HTML content and appears to Appium as a separate context with its own document and element tree.

The default Android automation driver in modern Appium, built on Google's UiAutomator framework, which exposes the Android view hierarchy for element location and interaction.

The Apple automation framework, and the Appium driver built on it, that controls iOS apps through the accessibility layer and is used for both simulators and real devices.

A strategy plus value, such as accessibility ID or XPath, used to find a UI element in the current context so that commands can be applied to it.

A locator strategy that matches an element's accessibility identifier or content description, generally the most stable and cross-platform way to find elements in Appium.

A path expression language for navigating an XML tree, usable in Appium to locate elements by hierarchy and attributes, though it is slower and more brittle than dedicated locators.

A snapshot of the current screen's element hierarchy returned as XML, used to inspect available attributes and build or debug element locators.

A graphical tool that connects to a running session, displays the live screen and element hierarchy, and helps authors discover locators and record interaction steps.

A session-wide timeout that makes element lookup commands retry until an element appears or the limit expires, applied globally rather than per individual command.

A targeted wait that polls for a specific condition, such as element visibility or clickability, with a defined timeout, giving more precise control than a global implicit wait.

A configurable wait that repeatedly applies a condition while ignoring specified exception types, with adjustable polling interval and overall timeout, offering fine-grained synchronization control.

The practice of making tests wait for the app to reach an expected state before acting, avoiding fixed sleeps and reducing flakiness caused by timing differences between test and device.

A test property where results vary between runs on unchanged code, often caused by timing, unstable locators, or device state, and mitigated by proper waits and robust element selection.

A low-level gesture API that composes press, move, and release steps into a sequence, used for taps, long presses, swipes, and multi-touch gestures on the screen.

The standardized WebDriver input API that models pointer, key, and wheel inputs as timed sequences, replacing older touch APIs and supporting multi-finger gestures portably.

A gesture that drags a finger across the screen, commonly used to dismiss cards, reveal menus, or navigate pages, implemented by composing pointer down, move, and up steps.

Moving content within a scrollable view to bring off-screen elements into view, often done with mobile scroll commands or gesture sequences until the target is found.

A service or lab providing many real devices and simulators for running automated tests in parallel, helping validate behavior across manufacturers, screen sizes, and OS versions.

A software environment that mimics an Android device, running the operating system virtually on a computer so tests can execute without physical hardware.

Apple's virtual iOS device environment that runs on a Mac and imitates device behavior for development and testing, though it cannot reproduce all hardware characteristics.

Physical hardware used for testing, capturing true performance, sensor behavior, and manufacturer customizations that virtual environments may not reproduce faithfully.

Running multiple sessions concurrently across devices or emulators to shorten total execution time, requiring distinct device identifiers and non-conflicting server ports.

Driving a mobile browser through Appium to test a mobile web application, using browser-specific capabilities and standard web element locators within the page.

A URL that opens a specific screen or feature inside an installed app, useful in tests to jump directly to a state instead of navigating through the UI.