Testing a web app using mobile devices

When testing a web-based application from a desktop environment you typically have to do a lot of configuration testing, meaning you test the web app using different browsers in different versions on different operating systems. Developers are quite well used to this set up and there are a number of tools and rules of thumb to help. When it comes to testing the web app using mobile devices, the ground is not as well trodden. Here are a few tips to help you along the way:

1: Cover your bases

Mobile phones, like the desktop environment, come in all shapes, sizes and configurations. You need to find a method in the madness, and a way to do so is by splitting the whole down into more manageable parts which need to be covered in your testing. Examples of 4 classes could be:

• ‘feature phones’, fairly standard phones but which have a few ‘extra’ features, for example the Nokia 6303, which has a browser, camera and a fair amount of functionality, but can not be considered a smart phone.
• ‘smart phones with low level support’ – some of the more budget friendly phones with almost all of the features of contemporary smart phones
• ‘smart phones’ such as iPhone and the Nokia Lumia 900
• ‘tablets’ such as the iPad and the Samsung Galaxy Tab

Select test devices to cover all the categories above to make sure you don’t miss any important classes.

2: Use the stats

Check what your traffic stats say. If a high percentage of your traffic comes from iOS user agents, and only a handful visits per month are made on Symbian phones, it would be wiser to concentrate on the area where attention is most needed.

In general, for the past couple of years, it’s fairly safe to say that the primary tablet market will be 7-inch devices up to 720×1280 pixels and the lowest smart phone at 240×360 pixels, however this depends on your particular project setting and usage.

3: Test on devices

Emulators are very useful in a lab setting but unfortunately they do miss things which are only uncovered when using the handsets themselves. There are a number of nuances between each and every device which you will discover as you use each of them. Furthermore remember that mobile testing is tricky for other reasons, including the fact that you can’t remotely test a tactile UI, and that testing how an interface reacts when the phone enters a 3g network black spot is not always so simple.

4: Bear updates in mind

Keep in mind that rate at which mobile users update their phones and browsers is really quite a rapid one. In the developed world the typical contract length for a smart phone is somewhere between 18 months and 2 years, meaning that there’s a fairly quick upgrade cycle from year to year and that a well sized segment of the market will always be using the latest technology, and these users typically expect the latest and greatest experience.

On the other hand, bear in mind that portions of your audience might be using low-end devices for an extended period of time. Some developing economies appear to be using Nokia phones almost exclusively, and these will usually be running Opera or the native s40 browser. A simple trip to a local phone shop will immediately demonstrate that manufactures are constantly pushing a vastly different set of phones to their customers, and you have to accommodate for as many of them as possible, even into the future.

5: Create a ‘core experience’

The big question you’re probably asking now is “How can we continue to support older, less capable devices while delivering an excellent experience tailored to smart phones and larger resolutions?”

Well, you do this by setting yourself a lowest common denominator and developing towards that. The lowest common denominator or ‘core experience’ is the core functionality, the stuff that has to work everywhere, regardless of platform and other configurations. Think of the core experience as something simple which always needs to work, be it on smartphone, tablet, desktop browser, a text-browser like Lynx, a phone where JavaScript has been disabled, and even the GoogleBot. Essentially, what you’ll be focusing here is core functionality and speed.

In the past, you could’ve chosen a minimum point of entry, say, Internet Explorer 6, and just keep at the code until it fits the bill completely in IE6. These days, this is a redundant exercise, as using feature deduction is a more obvious and painless solution.

6: Think for mobile.

We wouldn’t have any of the problems above if only we had the benefit of forethought, and lots of it. The excellent download speeds that broadband has given us allowed us to stop worrying about how large our web pages were and this was carried on to mobile platforms which don’t always have broadband speeds or hardware capacity to render complex code.

The ever increasing popularity of mobile web browsing, and the availability of responsive web design will force you and many others to think differently about a modern webpage should be built. As of today, you simply have to think in terms of: “Is it responsive, does it work on everything, does it look great, and is it very fast?”