You cannot test on every phone. A device matrix shows which combinations you did cover, so gaps are visible instead of assumed. It is a plain table you can paste into a spreadsheet.
Copy-paste template
Paste into a spreadsheet; the pipes work as column separators in most tools, or use Tab.
Device | OS version | Screen size / type | Why this device | Build tested | Core flows | Date | Tester | Issues found
[Model] | [Android 14] | [6.1" phone] | [popular / oldest we support / small screen] | [n] | [pass / fail / not run] | [date] | [name] | [links]
Rows to include, as categories rather than specific models:
1. Your own main phone (daily use)
2. Oldest OS version you support
3. Newest OS version, including a beta if you plan for it
4. Smallest screen you support
5. Largest phone or a tablet, if you support tablets
6. A low-memory or slow device
7. A different manufacturer skin (Android) or an older iPhone model (iOS)
8. Different settings: dark mode, large font size, other language, gestures vs buttons
Example (invented)
Device | OS | Screen | Why | Build | Core flows | Date | Tester
Test phone A | Android 14 | 6.1" | main phone | 57 | pass | 2026-10-14 | Sam
Test phone B | Android 10 | 5.0" | oldest supported, small | 57 | fail: cut-off button on Stats | 2026-10-14 | Alex
Emulator | Android 14, font 200% | 6.7" | large-font setting | 57 | not run | - | -
How to use it
- Decide the minimum OS version first. It sets the oldest row.
- Pick by differences, not by popularity alone. Two phones with the same screen and OS find the same bugs.
- Mark "not run" explicitly. A blank cell looks like a pass.
- Record the build. A pass on build 55 says nothing about build 57.
- Use your own data. Check your store console or analytics for the devices and versions your users have, and let that fill the "Why" column.
- Ask testers for device and OS with every report, and add them to the matrix.
For a worked approach to picking Android devices, see which Android devices to test on.
How to adapt it
- Add columns that matter to you, such as orientation, network (Wi-Fi/mobile/offline) or language.
- Emulators are fine for layout and OS checks; confirm performance and sensors on real hardware.
- Shrink the matrix for small apps: four well-chosen rows beat twenty random ones.
Related: risk-based testing, user acceptance test checklist, and the hub mobile app testing checklists.
Short on devices? Start free and get feedback from testers on theirs.