Device testing, explained without the jargon

There is no clever trick in this one, just a handful of decisions worth making deliberately. Here is device testing without the vocabulary that usually surrounds it.

You do not control the device, the network, or the operating system version, and the design has to accept that. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

The newest phone is not the phone your customers own. The reasoning matters more than the rule, because the rule has exceptions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. In practice this is a scheduling problem more than a technical one.

Test on mid-range hardware and poor networks. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

A reasonable first step

Automate the regression path, test the rest by hand. The teams that handle this well are rarely the ones with the biggest budgets. It rarely shows up as a line item, which is exactly why it slips.

The short version

Mobile releases are slower to correct than web ones, so the cost of shipping a mistake is higher. Three things worth confirming about device testing before you move on:

• Someone can say what the current setup is without going to look
• Automate the regression path, test the rest by hand — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.