Mobile Devices and Platforms
This domain is the hardware and OS layer of the syllabus: what a device contains, how platforms fragment, and which environment - emulator, simulator, real device or cloud device farm - can actually expose a given defect.
Emulator, simulator, real device
- Emulator - software model of hardware and OS (e.g. Android Emulator). Cheap, scriptable, good for early functional checks; hardware behaviour is simulated.
- Simulator - reproduces OS/API behaviour but not device hardware (e.g. iOS Simulator). No camera, telephony, Bluetooth, real sensors or battery.
- Real device - required for performance, battery drain, memory pressure, camera, sensors, radio/carrier behaviour, OEM customisations and interruptions. Cloud device farms give remote access to real hardware.
Platform fragmentation
Android spans many OS/API levels, vendor skins, minimum/target SDK settings and slow update adoption. iOS has fewer active versions and fast adoption, but older supported devices still matter. Read your analytics, define a minimum supported version, and test at both ends of the range.
Networks
Cellular generation, bandwidth, latency, jitter, packet loss, Wi-Fi-to-cellular handover, airplane mode, captive portals and roaming all change behaviour. Network-condition simulation exposes timeouts and retry logic that office Wi-Fi hides.
Worked example
A delivery app's GPS tracking passes on the simulator, where locations are injected on demand. Outdoors on real hardware the fix is slow or drifting, so the app shows stale positions. Reasoning: the simulator removes the very variable under test (radio-based location), so this needs field testing on real devices with recorded routes and weak-signal conditions.
Traps that cost marks
Assuming a simulator has a camera or telephony; choosing devices by "newest flagship" instead of user analytics; ignoring an OS update that lands mid-project; testing only one network profile.