ISTQB CT-MAT key terms

Testing activities applied to software running on mobile devices, covering functionality plus device-specific risks such as connectivity, sensors, battery, screen size, and app store distribution rules.

The wide variation across mobile devices in screen size, resolution, OS version, chipset, memory, and manufacturer customization, which multiplies test configurations and defect risk.

An application built with platform-specific languages and SDKs, installed as a package, and able to use full device capabilities and platform UI conventions.

An application delivered through a mobile browser and accessed by URL, with no installation, limited access to native device features, and dependence on browser and network behavior.

An application whose UI is largely built with web technology and wrapped in a native container, combining web portability with access to selected device APIs through a bridge.

An embedded browser component inside a native app that renders web content, introducing its own risks around rendering differences, session handling, and bridging to native code.

A layout approach that adapts content to different screen sizes and orientations using flexible grids, images, and media queries, requiring verification across viewports and rotations.

The number of pixels per physical unit of screen area, expressed as dots per inch or platform-specific scale factors, affecting image sharpness, layout scaling, and touch target size.

The interactive area that responds to a tap or gesture, which must be large enough and spaced far enough apart to be reliably usable by a finger.

Verification of touch interactions such as tap, long press, swipe, pinch, zoom, drag, and multi-finger gestures, including boundary behavior and accidental gesture handling.

Rotation between portrait and landscape that can recreate activities, resize layouts, and lose unsaved state, so tests check state retention and layout correctness after rotation.

Testing how the app behaves when events such as incoming calls, messages, notifications, alarms, low battery alerts, or system dialogs suspend, overlay, or resume it.

The lifecycle states of an app when it is not visible versus actively used, where behavior on suspend, resume, and termination affects data integrity and user experience.

The app's ability to return to a consistent and expected state after interruption, process death, rotation, or navigation back, verified against saved and reloaded data.

Exercising the app under varied connectivity such as 2G, 3G, 4G, 5G, Wi-Fi, high latency, packet loss, and offline mode to check timeouts, retries, caching, and messaging.

A designed behavior that lets users continue some tasks without connectivity, requiring tests for local storage, synchronization, conflict handling, and clear user feedback.

A test technique that simulates bandwidth limits, latency, jitter, and packet loss to reproduce real-world mobile network conditions in a controlled way.

Measuring and evaluating how much power the app uses during typical and heavy scenarios, especially background activity, location tracking, network polling, and sensor use.

Verification of app behavior driven by device sensors such as GPS, accelerometer, gyroscope, camera, microphone, and biometrics, including permission and unavailable-sensor cases.

Checking how the app requests, uses, denies, and revokes runtime permissions, including behavior when the user refuses, changes settings later, or grants limited access.

A software environment that imitates a mobile device and OS on a computer, useful for broad configuration coverage and early testing but limited in hardware and performance fidelity.

A tool that models device behavior at a higher level without emulating hardware, fast for functional checks but unsuitable for validating real performance and sensor behavior.

Executing tests on physical handsets and tablets to reveal hardware, performance, network, and vendor-specific defects that emulators and simulators may miss.

A hosted or in-house collection of real devices, often cloud-accessible, used to run automated and manual tests across many models, OS versions, and carriers.

Testing the app across combinations of device model, OS version, screen size, language, network, and settings to find defects tied to specific environments.

Verification of install, update, upgrade, downgrade, reinstall, and uninstall flows, including storage requirements, interrupted installs, and data retention expectations.

The publisher-side gatekeeping process that checks policy, privacy, metadata, and technical compliance before an app or update becomes available to users.

Releasing a pre-production build to a limited group through platform beta channels or public testing tracks to gather crash data and feedback before full release.

Collection and analysis of crash and non-fatal error data from devices, used to prioritize defects and understand field failures by device, OS, and app version.

Evaluating responsiveness, startup time, memory use, CPU load, rendering smoothness, and stability under realistic device and data conditions.

A defect where allocated memory is not released, causing growing consumption over time that can slow the app or trigger termination by the operating system.

Assessment of how effectively and comfortably real users complete tasks on a mobile device, considering touch precision, small screens, one-handed use, and context of use.

Checking that the app is usable with assistive technologies and settings such as screen readers, large text, high contrast, and alternative input methods.

Verifying translated text, formats, currencies, dates, right-to-left layouts, and cultural appropriateness across supported languages and regions.

Checking that the app collects, stores, transmits, and shares personal data lawfully and transparently, including consent flows, tracking, and data minimization.

Assessing mobile-specific risks such as insecure storage, weak transport security, improper session handling, excessive permissions, and vulnerable third-party libraries.

Using tools and scripts to execute repeatable mobile checks, often through platform UI automation frameworks or cross-platform drivers, run locally or on device farms.

A tendency of automated tests to pass and fail inconsistently on unchanged code, common in mobile due to timing, animation, network, and device variability.

Observing live app behavior in production through telemetry such as crashes, latency, and usage metrics to detect issues that testing did not reveal.