An app can pass a demonstration on the developer's phone and still fail for a customer with a smaller screen, an older operating system or unusual text settings. A useful test plan covers the combinations most likely to affect the task. It does not require buying every phone. It requires a deliberate device sample and a short set of demanding, repeatable journeys.
Select devices by risk
Start with the actual staff fleet or customer evidence. Include a lower-performance supported phone, a small screen, a large screen and each target operating system. Add any device tied to a scanner, printer or other accessory. Android's testing guidance distinguishes different test scopes and execution environments; automated checks and emulators are useful parts of a broader approach. Real hardware remains important for your particular camera, keyboard, permission and interruption experiences. Write down the supported range so failures near its boundaries are treated consistently rather than dismissed as unusual.
Use a journey matrix
For a mobile booking app, the matrix might include a new booking, a changed appointment, a failed payment handoff and cancellation. Run the most consequential journeys on every representative device. Then layer conditions such as no network, expired sign-in, large text and interruption by a phone call. Avoid multiplying every condition into an unmanageable grid. Prioritise combinations that could lose work, mislead a customer or stop an essential task. Keep the test data realistic, including long addresses and a customer with several similar bookings.
Record evidence that leads to a fix
A useful issue report names the device, app version, steps, observed behaviour and intended outcome. Include a short recording where it helps, removing private customer information. Distinguish a visual imperfection from an inability to complete a task, then assign severity accordingly. Before release, rerun the affected journey on the relevant devices and check neighbouring behaviour that the fix might disturb. Preserve a small acceptance checklist for future updates. The objective is confidence in the customer's work, not an impressive count of test cases that all exercise the same easy screen.
- Which supported device is most likely to reveal performance or layout problems?
- What failure could lose work or make a customer believe the wrong thing?
- Does every defect report contain enough information to reproduce the problem?
- Which essential journeys will be repeated before each customer-facing update?