Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Tips for application testing on mobile devices

Mobile and touch screen devices promise new directions of features, and, along with that, new failure modes and risks. How then, should we test? Matt Heusser shares his experience and some reminders about important considerations when testing mobile devices.

So there I was, on my iPod Touch, trying to get to a list of users whose name started with the letter “I.” It worked great on the simulator with a mouse, but with the actual iPod, my finger was too fat to click the single line of pixels.

Suddenly it hit me: This is different. Sure, all of the old GUI rules apply, but suddenly we have a new set of ways the application can fail. This tip provides a quick set of guidelines to consider, primarily for Web-based mobile applications, but much of it applies to native applications as well.

Screen real estate

You might use a mobile device just like a regular 1024x768 pixel application, but your users probably won't. Try to actually use the application on a number of devices -- just use it. You'll likely come away suggesting a mobile interface, perhaps an automatic re-direct on login when your application senses a mobile device. Even then, you'll want to explore the application in a number of devices, looking for usability problems.

The supported device problems

iPods, Blackberrys, Android, and other smart phones may all be running a different browser, so complex Javascript is likely to work on one and fail on another. My recommended fix to this is similar to the one for screen real estate: Develop a simplified "mobile" interface that uses vanilla HTML.

Conversions between interfaces

If you develop a mobile interface, you'll likely want a way for the users to switch back to the "full" interface and mobile. This should be seamless. You may even want to test the "full" interface on a mobile device, to some extent, for the sake of your power users.

Does the app need a continual connection?

Some applications are designed to be "always on" the internet. That works fine if you have a physical wire and paid-for Internet, but consider the mobile device: What if the user is in a coffee shop and steps away? What if the user is on a 3G network and switches cell towers, goes roaming, or out of range?

For voice, video, and other high-data applications, you may want to find a way to "yank the wire," to simulate loss of connectivity. Likewise, you may want to let the machine go to sleep (or simulate putting it away in a purse for two hours), then wake it up, perhaps on a different data network.

Speaking of different data network, consider interrupts -- what happens when the user receives a phone call, gets an email, or some social media game pops up a note that his peanuts are ready in VilleVille, then wants to go back to your application?

Touch screens and links

Driving a simulator just doesn't give the same feel as using the active device. Make sure you get some hands-on device exploration time. Try using the device in bed, or in a chair, while walking, or exposing it to g-forces -- put it in a handbag and swing it. Try handing the app from one person to another over a table, or rotating it 45 or 90 degrees to see if the screen will “flip.”  

For that matter, fingers are different than thumbs, and right-handed use might be different than left, like it was on the iPhone 4. You'll be surprised what you might find; one helpful site to consider is the Apple Human Interface Guideline.

Mobile download speeds

At some point in testing web applications I stopped worrying about dial-up users. Well, thanks to 3G data plans, everything old is new again. Yes, you'll want to see how performance is over a slow connection.

How do you close windows, anyway?

I find that many phones have a “back to home” button, but the way to close an application may be unclear. This means that after six months of use, the user may have dozens of applications running in memory -- a memory space that is smaller than your typical netback. So while low memory errors might not be a risk on a Web-based application for the PC, it's certainly something to look at when you go mobile.

How do I get the app?

With most web applications you “just” need a URL, but native applications typically require a download from some sort of store. You’ll want to find out if the application is discoverable, if the description is accurate, and if the install process is usable. Along the way, you’ll want to use the rules of thumb above: What happens if i lose my connection while downloading? Is it reasonable to browse for and download the application on a small touch screen? 

The application may require registration, and that process might take a fair amount of typing and clicking; you’ll want to see how well that process works on your preferred mobile devices as well.

What’s next?

This article had one goal: Given a mobile device and an application, equip the reader to test.  Sadly, there’s a lot more to mobile testing than that; there is negotiating scope, dealing with simulators, issues with budget, finding the time to support all the new platforms, figuring out how and what to automate, and the list goes on.  

Right now you can always practice: “just” pull out your cell phone or iPad and give your current app (or favorite website) a whirl using these guidelines. 

Do you hear that sound? I do believe it is opportunity knocking.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.