Imagine a restaurant where you could just walk up and order whatever you felt like—no menu, just anything you want. If you felt like eating a salad, the restaurant would make you a salad. If you felt like a steak, it would make you steak just the way you liked it. If you wanted a banana, peanut butter, and potato chip sandwich, it would make it. Or, if you felt like ratatouille niçoise, in which each ingredient is sautéed separately, layered together, then baked to perfection (the proper way to prepare this delicious dish, by the way), it would make that for you, too. If you are the only customer, then this restaurant would certainly be a dream come true, because the chef would have time to focus and prepare your dish to perfection. It would probably be one of the best meals you’ve ever had in your life.

But, of course, as more customers enter our fictional restaurant and as more custom orders are placed, the kitchen would become a nightmare. The chef, regardless of his training and expertise, would have to deal with so many variables that not only would it become unmanageable, but the quality would start to decrease. It becomes impossible to create so many variations and still maintain a high degree of quality.

This is the case with the task of testing mobile devices, and unfortunately, we are the chefs. Dealing with one device is easy, but as you start adding more and more devices the variables/variations become too great to manage. Maintaining quality and consistency moves further out of reach.

Many developers tell me, “No problem! Let’s be great on one and OK on another.” A wise strategy, maybe, for the mobile web, but for native applications, OK is often not quite good enough. In order to get your native applications downloaded onto your users’ devices, the applications will need to be certified and approved by at least one organization outside of your own—an opaque process regardless of what channel, platform, device, or operator you intend to work with.

Another lazy strategy is to dismiss personally testing devices altogether and assign them to a QA resource or outsource it entirely. Unfortunately, it is not that easy. Good mobile design and development requires that everyone be a part of ensuring that the work they do ends up on devices correctly, making sure that your experiences are usable and valuable to the user. Testing does not simply occur at the end of the project, but throughout the process.

Keep in mind that there is no one foolproof way of testing your work on devices. It takes flexibility and often some creativity to find the right solution for your resources, project, or company. This chapter discusses some of the various techniques and best practices for testing your work on devices and trying to cost-effectively support as many devices as you possibly can.