ISTQB CT-MAT common mistakes
ISTQB CT-MAT · Understand the traps and how to avoid them.
Treating mobile testing as a smaller version of desktop web testing: answering questions as if the app runs on a stable network, a single device, and a plugged-in power supply, and omitting device fragmentation, intermittent connectivity, and battery or thermal constraints from scenario answers.
Candidates transfer habits from web or desktop certification study, where the test object is assumed to be one browser on one machine; mobile-specific constraints are not part of their existing mental model, so they go unnoticed rather than being deliberately excluded.
What to do instead
Before answering any scenario question, run a fixed checklist: device and OS fragmentation, network conditions (2G/3G/4G/5G, offline, high latency, handover), battery and thermal state, interrupts (calls, notifications), and store/distribution constraints. Build answers from that checklist rather than from desktop intuition.
Classifying test types incorrectly on mobile-specific triggers: labelling an incoming phone call during a session, a network switch from Wi-Fi to cellular, or a push notification arriving mid-transaction as purely functional testing, instead of recognising the interrupt, connectivity, and reliability dimensions they exercise.
These events look like user actions and are therefore filed under functional testing, but the exam expects candidates to reason about which quality characteristic is being stressed (reliability, portability, performance efficiency) and to map test activities to those characteristics.
What to do instead
Practise mapping each mobile event to the quality characteristic it stresses and to the test type that targets it. Write a two-column table (event, quality characteristic plus test type) for interrupts, network transitions, low memory, rotation, and background/foreground switching, and revise it until the mapping is automatic.
Ignoring the mobile test pyramid and device-farm strategy: recommending manual execution on physical devices for everything, or conversely assuming an emulator or simulator validates real-device behaviour such as sensor input, camera, biometrics, or true performance.
Candidates either over-value hands-on device testing because it feels realistic, or over-value emulators because they are cheap and fast; both positions come from not having internalised the trade-off between fidelity, cost, and coverage across a fragmented device population.
What to do instead
Learn the standard trade-off explicitly: emulators and simulators are strong for early functional checks, fast feedback, and hard-to-reach configurations; physical devices are required for hardware-dependent behaviour, real performance, and battery or thermal effects. In answers, state which level you use and why, and combine automated regression on a device cloud with targeted manual testing on a risk-selected physical device set.
Missing the store-release and update dimension: answering release questions without addressing app-store review cycles, staged rollouts, forced versus optional updates, backward compatibility with older app versions still installed, and the impossibility of instant rollback.
Candidates reason about deployment as a continuous-integration pipeline that ends at a successful build, without accounting for the distribution gatekeeper and the fact that users control when (or whether) they update.
What to do instead
Treat distribution as part of the test basis. For every release question, address review lead time, staged/phased rollout percentages, feature flags and remote configuration for kill switches, server-side backward compatibility with at least the previous app version, and the test data needed to validate forced-update and skip-update paths.
Under-testing interruption and state-restoration scenarios: covering only the happy path of launching and using a screen, and omitting backgrounding, process death under memory pressure, screen rotation, split-screen, and resuming mid-flow with unsaved data.
These paths are invisible in a short manual session on a healthy device; they only appear when the operating system reclaims resources or the user switches context, so candidates who test as users rather than as testers never encounter them.
What to do instead
Design explicit interruption test cases: send the app to background mid-transaction, kill it from the task switcher, rotate the device, trigger a low-memory warning, and resume. Verify state restoration, no data loss or duplication, and correct handling of in-flight network requests. Include these as a standing regression suite rather than one-off checks.
Confusing mobile performance testing with functional testing: checking that a screen loads at all, rather than measuring cold and warm start time, time to interactive, memory footprint, battery drain, data usage, and behaviour on low-end hardware or degraded networks.
Performance is often reduced to 'is it fast enough on my phone', which is subjective and measured on a high-end device with good connectivity; candidates lack concrete metrics and thresholds to reason about.
What to do instead
Memorise the measurable mobile performance indicators and the conditions that expose them: cold versus warm start, frame rendering and jank, memory growth and leaks, battery and network data consumption, and behaviour under throttled network and CPU. In answers, name the metric, the target threshold, and the device or network profile used to measure it.
Answering security questions with generic web-security content only, omitting mobile-specific risks: insecure local storage of tokens and personal data, excessive permissions, weak transport security or certificate pinning, jailbreak/root detection, and reverse engineering of the app package.
Candidates rely on familiar web topics such as injection and cross-site scripting and do not consider that a mobile app package and its local storage are physically available to an attacker on the device.
What to do instead
Build a mobile-specific security checklist: data at rest on the device, keychain/keystore usage, permission minimisation, secure communication and pinning, session and token handling, tamper and root/jailbreak detection, and what is exposed in logs and backups. Practise mapping each item to a concrete test technique.
Mishandling usability and accessibility for mobile contexts: judging usability by desktop conventions, ignoring touch-target sizing, one-handed reach, gesture discoverability, platform-specific navigation patterns, screen readers, dynamic text size, and colour contrast in outdoor light.
Candidates apply general usability heuristics without adapting them to small screens, touch input, and platform human-interface guidelines, and accessibility is often treated as a separate specialised topic rather than part of every mobile review.
What to do instead
Learn the platform guidelines and the measurable accessibility criteria (touch target size, contrast ratio, support for dynamic type and screen readers, focus order). Practise reviewing a described screen against those criteria and phrasing findings as testable conditions rather than opinions.
Treating automation as record-and-playback across all devices: proposing a single recorded script that runs unchanged on every device and OS version, and ignoring locator fragility, synchronisation and waits, test data setup, and the maintenance cost of a fragmented device matrix.
Record-and-playback tools are easy to demo, so candidates assume the recorded artifact is the deliverable; they have not confronted flakiness caused by timing, animations, and OS-level dialogs that differ between devices.
What to do instead
Design automation around stable element identification, explicit synchronisation instead of fixed sleeps, and abstraction of device-specific steps. Prioritise what to automate (stable, high-value regression) versus what to keep manual, and justify the chosen device coverage by risk rather than by trying to cover everything.
Skipping defect-reporting specifics for mobile: filing defects without the device model, OS version, app build, network conditions, and reproduction steps, and failing to distinguish device-specific defects from defects reproducible everywhere.
Candidates draft defect reports as if a single environment existed, so environment data feels optional; in mobile, the same defect can be invisible on one device and constant on another, which changes triage and priority.
What to do instead
Use a fixed defect template for mobile: device and OS version, app build and variant, network profile, account and data state, preconditions, steps, expected versus actual, and reproducibility across devices. When answering, explicitly state whether the defect is device-specific or environment-independent and how that affects severity and priority.