Three myths about device testing

The version of this that works is simpler than the version most people imagine. A few things about device testing that get repeated more often than they get checked.

The version of the app your customers are running is rarely the one you just shipped. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

“It only matters for big sites”

The newest phone is not the phone your customers own. In practice this is a scheduling problem more than a technical one. It is the sort of thing that looks like polish right up until it costs you an enquiry.

“We can deal with it after launch”

Sometimes true, usually expensive. Where this goes wrong is almost never a lack of knowledge.

“Our platform handles it”

Automate the regression path, test the rest by hand. There is a version of this that is over-engineered, and it is worth avoiding. It rarely shows up as a line item, which is exactly why it slips.

How to tell if yours is fine

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
• Test on mid-range hardware and poor networks — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.