A4Q Foundation Level Tester for Appium flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Native application

An app compiled against platform SDKs using native UI widgets. It delivers top performance and full device API access but requires a separate build and test suite per operating system.

Mobile web application

A site accessed through the device browser rather than installed. One codebase serves all platforms, but it depends on browser version and has limited access to device hardware features.

Hybrid application

A native container hosting a WebView that renders HTML/JS content. Testers must automate both the native shell and the embedded web content, switching contexts between them.

WebView

An embedded browser component inside a native app that renders web content. Automation tools treat it as a separate context from the native UI layer.

Interrupt testing

Testing app behavior when external events occur mid-session, such as incoming calls, messages, notifications, or system dialogs, verifying the app resumes correctly afterward.

Device fragmentation

The spread of devices across OS versions, screen sizes, densities, and manufacturers. Test coverage is prioritized using real-world usage share data rather than covering every model.

Network condition testing

Exercising the app under varied connectivity: slow links, high latency, packet loss, airplane mode, and switching between Wi-Fi and cellular, to confirm graceful degradation.

Upgrade testing

Verifying that installing a new app version over an older one preserves required user data and settings, and that migration logic runs correctly without data loss.

Cold start time

The duration from launching an app that is not in memory until the first usable screen appears. It is a key performance metric measured on representative devices.

Test pyramid for mobile

A layered test strategy with many fast unit tests, a service/API layer, and few slow UI tests. It reduces execution time and flakiness compared with UI-heavy suites.

Screen density

The number of pixels per physical inch on a display, expressed as dpi buckets on Android. Layout and asset scaling must be verified across density classes.

Appium architecture

A client-server model: the test client sends W3C WebDriver HTTP commands to the Appium server, which translates them to platform automation frameworks that drive the device.

Desired capabilities

A JSON set of session parameters sent at session creation. platformName is required; app or appPackage/appActivity, automationName, and deviceName identify the target.

automationName capability

Selects the driver engine on the platform, for example XCUITest on iOS or UiAutomator2 and Espresso on Android. It determines which locator strategies and gestures are available.

app capability

Points to the application file to install, such as an .apk on Android or .ipa/.app on iOS. Alternatively bundleId or appPackage with appActivity targets an already-installed app.

noReset capability

When true, the app state and data are preserved between sessions and the app is not reinstalled. Useful for faster reruns but can hide first-launch defects.

fullReset capability

When true, the app is uninstalled and reinstalled before the session, clearing all data. It guarantees a clean state at the cost of longer session startup.

Context switching

Changing the automation target between NATIVE_APP and a WEBVIEW_* handle. Required for hybrid apps; native commands fail while a webview context is active.

getContextHandles

An Appium command returning the list of available contexts, including NATIVE_APP and webview names. Testers use it to detect when a WebView has loaded before switching.

Accessibility ID locator

A cross-platform locator matching contentDescription on Android and accessibilityIdentifier on iOS. It is generally the fastest and most stable strategy when identifiers are set.

UiAutomator locator

An Android-only strategy using UiAutomator selector syntax, such as UiSelector().text(). It can reach elements by text, resource id, or class hierarchy.

iOS predicate string

An iOS locator written as an NSPredicate expression, for example name == 'Login'. It supports complex attribute matching and is faster than xpath.

XPath locator

A locator traversing the XML page source. It is the most flexible but also the slowest and most brittle strategy, so it should be a last resort in mobile suites.

W3C Actions API

A standardized way to build input sequences of pointer, key, and touch actions. It replaces the deprecated TouchAction class for tap, swipe, long press, and pinch gestures.

Implicit wait

A global timeout applied to every findElement call before failing. It is set once per session and applies to all locator lookups until changed or reset.

Explicit wait

A WebDriverWait polling a condition, such as element visibility or clickability, with a timeout. It targets a specific element and is preferred over fixed sleeps.

WebContentsDebuggingEnabled

An Android WebView setting that exposes web content to remote debugging. Without it, Appium cannot list or switch into the webview context for hybrid testing.

webview context detection

The process of polling getContextHandles until a WEBVIEW_* entry appears after navigation. The switch must wait for page load or commands will fail.

Parallel mobile execution

Running sessions concurrently across devices. Each device needs a unique UDID and systemPort, and typically its own Appium server or grid node to avoid port conflicts.

Appium Inspector

A GUI tool that connects to a running session to display the page source tree, element attributes, and suggested locators, aiding locator selection and debugging.

Page source command

Retrieves the current UI hierarchy as XML, reflecting the active context. It is the basis for xpath queries and for diagnosing why a locator fails.

Screenshot on failure

Capturing device screen state when a test fails, usually in a teardown hook. It provides visual evidence and speeds triage of flaky or environment-related failures.