A device matrix is a justified set of devices and configurations for mobile testing. It covers significant risks within available time. A collection of expensive phones and a long unexplained model list are equally poor foundations for release decisions.
A useful matrix shows which user groups are represented, which platform characteristics are checked, and what was tested on each device. Device count alone answers none of these questions.
Where to obtain baseline data
Start with product analytics: models, OS versions, active-user shares, and key-market characteristics. Compare them with failures and support requests. A popular device with recurring problems deserves attention even with ordinary specifications.
For a new product, use audience hypotheses, minimum system requirements, and available market data. Mark assumptions and set a review date; a provisional matrix should change when real traffic arrives.
Which dimensions matter
Do not require every possible characteristic combination. Select properties capable of affecting your particular application.
- →OS version, including minimum support and versions actually used
- →Performance, memory, and available storage
- →Window size, screen density, cutouts, and navigation characteristics
- →Manufacturer and background-work restrictions
- →Camera, biometrics, NFC, and other required hardware
- →Locale, text size, input methods, and accessibility tools
Maps depend on location; banking depends on secure login; video catalogs depend on memory and decoding. Reflect these differences in the matrix.
Separate audience coverage from risk
High user share helps select primary configurations, while a rare device can represent an important risk: minimum OS, low memory, or a foldable screen. Record those reasons explicitly.
Do not add percentages from independent dimensions. Covering 80% of models and 90% of OS versions means neither 170% coverage nor guaranteed coverage of 80% of users. Accurate estimates require joint configuration statistics and a clear denominator.
Testing depth
Run critical journeys on the core set for every significant release. Use the extended set for targeted compatibility, platform changes, and risk areas. Rare hardware scenarios can be triggered by relevant feature changes.
Keep the extended set active with an owner, frequency, and trigger. A camera update needs physical capture testing even after an emulator smoke passes.
Practical example: a delivery application
Consider six physical devices and limited cloud-lab access. Core operations are login, address entry, cart, payment, and order tracking.
- 1.Choose a common midrange Android and a common iPhone as primary configurations.
- 2.Add an Android with the minimum supported OS and limited memory to test the support boundary.
- 3.Add a manufacturer's device associated with frequent background-update support issues.
- 4.Include a small screen for address forms and a large screen for adaptive layouts if supported.
- 5.Complete the full order journey on the core set. On the others, check address entry, keyboard, payment, and tracking recovery after backgrounding.
- 6.Record expectations and actual gaps, such as contactless payment remaining untested because suitable hardware is unavailable.
This report enables residual-risk assessment. “Tested on six phones” would hide the same limitations.
Where emulators and simulators help
Virtual devices support OS variants, window sizes, automation, and rapid state reproduction. Android explicitly recommends emulators for different platform versions and screen resolutions.
Confirm performance, radio behavior, battery use, and hardware integrations on suitable physical devices. Be especially careful comparing an iOS Simulator on a powerful computer with a phone: host specifications do not describe user hardware.
Using a cloud laboratory
Cloud labs broaden device access, but check limitations involving SIMs, location, accessories, notifications, system settings, and files. A remote device does not guarantee every physical scenario.
For complex defects, retain model, exact OS version, build number, logs, and video. Without these, a passing run on a similar cloud device may incorrectly appear to disprove the defect.
The matrix as a working document
Each row should state inclusion reason, specifications, scenarios, frequency, availability, and latest result. Record exact OS versions: after an automatic update, the previous configuration no longer exists.
Periodically compare the matrix with analytics and product changes. Dropping an old OS, growing tablet usage, or adding document scanning should change device selection and test depth.
Common mistakes
Brand-only selection misses behaviorally relevant properties. A full Cartesian product of every parameter makes the matrix impractical. Launching the application alone is insufficient evidence of compatibility.
Likewise, “Android tested” is misleading when only one model and OS version were used. A specific configuration represented the platform, and conclusions need visible limits.
Key takeaways for QA
A good matrix explains its configurations and connects each to user risk. Use analytics, defect history, and feature architecture; combine virtual and physical devices. Report completed scenarios and coverage gaps so release decisions rest on evidence.