ISTQB CT-MAT cheat sheet

Mobile app testing covers native, hybrid, and web apps; each type has a different test strategy emphasis: native focuses on platform APIs and device hardware, hybrid on the bridge between web content and native containers, web on cross-browser rendering.

Device fragmentation is the defining risk: testers must select a device matrix based on OS version share, screen size, resolution, chipset, and manufacturer customizations rather than testing every model.

Connectivity conditions to test include 2G/3G/4G/5G, Wi-Fi, airplane mode, network switching mid-session, high latency, packet loss, and intermittent loss of signal.

Interrupt testing covers incoming calls, SMS, notifications, alarms, low-battery prompts, and OS updates occurring while the app is foreground, background, or mid-transaction.

Battery, memory, CPU, and data-usage consumption are non-functional test targets; a common heuristic is that background behavior must not drain battery or consume data when the app is not in use.

Mobile security testing includes local data storage (keychain/keystore), transport security (TLS, certificate pinning), authentication/session handling, and permission scoping.

Usability on mobile is governed by touch target size, thumb-zone reachability, orientation changes, font scaling/accessibility settings, and gesture consistency with platform conventions.

Test automation on mobile typically uses Appium (cross-platform), Espresso (Android UI), or XCUITest (iOS); emulators/simulators are used for breadth, real devices for hardware-dependent and performance tests.

A mobile test strategy defines scope, device matrix, test types (functional, non-functional, compatibility, security), entry/exit criteria, and the environments (emulator, cloud device farm, real device) used for each.

Risk-based prioritization ranks features by business criticality and likelihood of failure; high-risk areas such as payments, authentication, and data sync receive deeper and earlier testing.

The test pyramid for mobile favors many unit tests, fewer integration/API tests, and a thin layer of UI automation because UI tests are slower and more fragile on devices.

Test environment considerations include OS versions, manufacturer skins, network profiles (Wi-Fi, cellular, offline), locale, and time zone; mismatched environments produce false passes or failures.

Entry criteria for mobile testing often include a stable build, defined device matrix, available test data, and configured network simulation; exit criteria include defect thresholds and coverage of prioritized risks.

Exploratory testing is essential on mobile because real-world interruptions, gestures, and connectivity transitions are hard to script exhaustively; session-based exploratory testing with charters is common.

Regression scope on mobile must include OS update compatibility, since a new OS release can break APIs, permissions, or rendering even when the app code is unchanged.

Metrics used to judge mobile test effectiveness include defect escape rate, crash-free session rate, device coverage percentage, and automation pass stability across the device matrix.

Mobile test tools fall into categories: automation frameworks (Appium, Espresso, XCUITest), device clouds (real-device farms), performance profilers (Android Studio Profiler, Xcode Instruments), and crash/analytics SDKs.

Appium uses the WebDriver protocol and supports native, hybrid, and mobile web apps; it requires platform-specific drivers (UiAutomator2 for Android, XCUITest driver for iOS).

Espresso is Android-only and runs in-process with the app, giving fast, synchronized UI tests; XCUITest is the equivalent Apple-provided framework for iOS.

Device farms provide access to many real devices over the network; they are useful for compatibility and smoke coverage but introduce latency and cost per test minute.

Emulators/simulators are fast and free but do not faithfully reproduce hardware sensors, camera, Bluetooth, biometrics, or real battery behavior.

Performance tooling examples: Android Studio Profiler and Xcode Instruments for CPU/memory/energy; network throttling tools for latency and bandwidth simulation.

Test management and defect tracking integrate with automation via CI pipelines; mobile CI must handle signing, provisioning profiles, and emulator/device provisioning.

Tool selection criteria include platform coverage, language support, maintenance cost, integration with CI, and whether the tool can drive real hardware features required by the test.

Test design techniques for mobile include equivalence partitioning, boundary value analysis, decision tables, state transition testing (app lifecycle, login states), and pairwise testing for device/OS combinations.

State transition testing is central because mobile apps have lifecycle states (foreground, background, suspended, terminated) and network states (online, offline) that change behavior.

Pairwise/combinatorial design reduces the device matrix: instead of full cross-product of OS, screen, and manufacturer, generate combinations covering every pair.

Boundary analysis applies to input fields, storage limits, file sizes, and timeouts (e.g., session timeout, retry counts, maximum upload size).

Use-case and user-journey testing covers end-to-end flows across screens and interruptions, verifying data persistence and recovery after backgrounding or crashes.

Negative testing on mobile includes invalid inputs, revoked permissions, disabled services (GPS, camera), low storage, and expired authentication tokens.

Accessibility test design checks screen reader labels, color contrast, dynamic type, and keyboard/switch access; these are testable conditions, not optional polish.

Exploratory charters target areas where scripts are weak: gesture handling (swipe, pinch, long-press), orientation changes, and multi-window/multitasking behavior.

Defect reports for mobile must include device model, OS version, app build/version, network condition, locale, and reproduction steps, because the same defect may appear on only one configuration.

Crash logs and stack traces are primary evidence; attach logcat (Android) or device console (iOS) excerpts and note whether the crash is reproducible on other devices.

Severity versus priority: a cosmetic layout defect on a popular device may be high priority, while a crash in a rarely used feature may be high severity but lower priority.

Common mobile defect classes include memory leaks, ANR (Application Not Responding) on Android, UI thread blocking, stale cached data, and permission-related failures.

Defect triage on mobile weighs frequency (how many devices/users affected) against impact; configuration-specific defects are tagged with the affected device/OS matrix cell.

Regression risk after a fix is assessed by checking whether the change touches shared code used across platforms or OS versions; retest on the original configuration plus representative others.

Root-cause categories help trend analysis: platform API change, third-party SDK, network handling, UI layout, data persistence, and lifecycle mishandling.

Metrics for defect analysis include defect density per feature, reopen rate, time to fix by severity, and distribution of defects across device/OS segments.

Mobile performance testing measures launch time, screen render time, frame rate (target 60 fps, 16 ms per frame), memory footprint, CPU usage, battery drain, and network payload size.

Cold start versus warm start: cold start includes process creation and is slower; both should be measured separately with defined thresholds.

Memory leak detection uses repeated navigation cycles and heap dumps; Android Studio Profiler and Xcode Instruments Leaks/Allocations are typical tools.

Network performance testing uses throttled profiles (e.g., 3G-like latency) and checks payload compression, image sizing, caching headers, and retry/backoff behavior.

Battery and energy testing identifies wake locks, background polling, and excessive GPS/radio use; energy impact is measured per scenario, not just per app session.

Server-side and API performance affect perceived app speed; test response times under expected concurrency and verify graceful degradation when the backend is slow or unavailable.

Performance acceptance criteria must be numeric and device-specific (e.g., launch under 2 s on a reference mid-range device) so results are comparable across runs.

Test stability requires controlled conditions: same device, same network profile, same build, and multiple runs to account for variance.

Mobile-specific security risks include insecure local storage of credentials, excessive permissions, weak TLS configuration, and sensitive data in logs or screenshots.

OWASP Mobile Top 10 categories include improper platform usage, insecure data storage, insecure communication, insecure authentication, insufficient cryptography, and code tampering.

Certificate pinning defends against man-in-the-middle attacks; testing verifies pinning is enforced and that the app fails safely when the pin does not match.

Data-at-rest testing checks keychain/keystore usage, encryption of databases and files, and whether sensitive data persists after logout or uninstall.

Authentication and session testing covers token expiry, refresh flows, biometric fallback, and session invalidation on logout or device change.

Permission testing verifies the app requests only necessary permissions, handles denial and 'don't ask again' states, and explains permission rationale.

Reverse engineering and tamper testing check for debug flags, root/jailbreak detection, obfuscation, and integrity checks; these are testable defensive controls.

Privacy testing verifies data minimization, consent flows, and that analytics/crash SDKs do not capture personal data contrary to policy.

Mobile test automation layers: unit tests (fast, host-side), integration/API tests, UI tests (slow, device-bound); balance investment toward lower layers.

Appium architecture: client sends WebDriver commands to an Appium server, which routes to a platform driver that controls the device; capabilities (platformName, deviceName, app) define the session.

Element locator strategies on mobile include accessibility ID, resource ID, XPath, and platform-specific predicates; accessibility IDs are preferred for stability.

Flaky mobile UI tests commonly stem from hard-coded sleeps, animation timing, network variability, and device-specific rendering; explicit waits and stable locators reduce flakiness.

Test data and state setup for automation requires resetting app state, clearing caches, and seeding accounts; otherwise tests interfere with each other.

Continuous integration for mobile requires build signing, emulator/device provisioning, and parallel execution across a device matrix to keep feedback time reasonable.

Automation ROI is highest for stable, high-frequency regression paths (login, core transactions); exploratory and one-off configuration checks are better done manually.

Reporting must capture device, OS, build, screenshots, and logs per failed test so failures can be triaged without rerunning on the device.

Compatibility testing covers OS versions (current and previous major releases), screen sizes/densities, manufacturers, chipsets, and locale/language settings.

Backward compatibility matters because users delay OS updates; define a minimum supported OS version and test at both the minimum and the current release.

Forward compatibility testing on beta OS releases identifies breakages before public rollout, giving time to fix before users update.

Cross-platform consistency checks that shared features behave equivalently on iOS and Android while respecting platform-specific conventions (navigation, back button, permissions).

Localization testing verifies translated strings, right-to-left layouts, date/number/currency formats, and text expansion without truncation.

Accessibility compatibility includes screen readers (TalkBack, VoiceOver), large text settings, and high-contrast modes across supported devices.

Hardware compatibility includes camera, GPS, NFC, Bluetooth, biometrics, and sensors; emulators cannot validate these, so real devices are required.

Interoperability testing verifies interaction with other apps and services: sharing intents, deep links, push notifications, and wearable or companion-device pairing.

Mobile app lifecycle states on Android include onCreate, onStart, onResume, onPause, onStop, onDestroy; on iOS, states include active, inactive, background, and suspended; tests must cover transitions between them.

Background/foreground transitions must preserve user state; a common defect is data loss or duplicate submission when the app resumes mid-transaction.

Interrupt testing simulates incoming calls, messages, notifications, and system dialogs during critical flows and verifies recovery and data integrity.

Process death (Android low-memory kill, iOS termination) requires state restoration testing: the app should recover or fail gracefully, not crash or show stale data.

Network transition testing covers Wi-Fi to cellular handover, airplane mode toggling, and offline-to-online sync, verifying retry, queueing, and conflict resolution.

Deep link and push notification testing verifies routing to the correct screen, correct handling when the app is closed, and authentication gating for protected screens.

Update and migration testing verifies that installing a new app version over an old one preserves user data and migrates local databases and settings.

Uninstall/reinstall testing checks that residual data, tokens, and cached credentials are cleared or handled according to privacy requirements.

Mobile test process phases: planning (scope, device matrix, risks), design (techniques, test cases, charters), execution (manual, automated, exploratory), and closure (metrics, lessons learned).

Test planning artifacts include the test strategy, test plan, device matrix, risk register, and estimation of effort per device/OS combination.

Monitoring and control use metrics such as test execution progress, defect discovery rate, and pass/fail trends to adjust scope and reallocate effort during the cycle.

Test closure criteria are defined up front: coverage of prioritized risks, defect thresholds by severity, and sign-off from product and QA leads.

Shift-left practices move testing earlier: unit tests, static analysis, and API contract tests run before device-level UI testing.

Continuous testing in mobile CI runs smoke and regression suites on every build and nightly full suites across the device matrix.

Traceability links requirements to test cases and defects; on mobile, traceability should also record which device/OS configurations validated each requirement.

Post-release monitoring (crash rates, ANR rates, ratings, analytics) feeds back into the test process as input for the next release's risk analysis.