Mobile Site Testing Overview
This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.
After your mobile site starts look complete in a development browser (e.g. desktop Firefox+Firebug combo) then it is time to begin testing it in actual mobile browsers. This blog post gives you introduction and some general tips for mobile browser testing. Each platform (iOS, Android, others) are dealt separately in the future blog posts, so don’t forget to follow.
1. The micro battle field of browser vendors
Like with desktop where you test your site across browsers you need to test the mobile site in different mobile browsers. The testing is important because mobile browsers use different browser engines and different engine versions. Thus, sometimes output differences are expected and you need to iron out the ugliest issues.
The major mobile browser engines are WebKit on Safari/Android, Opera (Presto) and Firefox (Gecko). You luckily could say that mobile Internet Explorer’s market share is so minor that you might want to bother for it currently. Microsoft is constantly improving its mobile browser, but currently it is not in a state to match the competition in feature wise and we’ll look forward to see what Windows Phone 8 will give us.
The good news are that if the mobile browser support CSS3 media queries, as used in the mobilization strategy of this tutorial, then they are likely to have very good support for HTML5, CSS3 and other modern goodies. The fixing and workaround work found during the testing is usually less than what it takes to make the site run older Internet Explorer.
If you need to define compatibility list of browsers e.g. for an offer I recommend use this jQuery Mobile mobile browser grading table. It gives you an overview how “good” mobile browsers are.
2. Accessing different mobile browsers on devices and simulators
If you aren’t a mobile developer you might not have access to a real test device repository. Luckily, the simulators by the mobile vendor themselves are pretty good nowadays and you don’t need to be physically able to access the every device out there.
It is desirable to minimally have one iOS and/or one Android device for testing. If you are targeting popular iOS devices (iPhone, iPad) it’s pretty hard to get around the fact that you need to get a Mac. Apple tools are only for Apple computers, like Microsoft mobile tools are only for the latest Windows 7.
There exist generic remote testing services for mobile phones, but they often are costly and not a substitute for the real thing.
3. No shortcuts to testing happiness
Warning: Do not use browser+<iframe>-based “mobile simulator” or whatever crap web search throws on you.
These so called simulators are usually pitiful attempts to grab web traffic for ad money without actually adding any value to testing. Running <iframe> based simulator in your web browser is simply the same as opening the page in your desktop web browser directly, with the window size shrink.
Typing on the mobile devices is cumbersome. Use URL shortening services like bit.ly to shorten your test page URLs, so you can type them in faster on touch screen or keypad.
4. Desktop web browser testing
If you need to alter HTML code or main CSS when mobilizing a legacy website you still want to see that your HTML changes did not introduce issues on the desktop browsers, especially older and problematic Internet Explorers. Here are some desktop testing resources, but I’d hope to hear of more pointers and services so please comment.
5. Internet Explorer virtual machines
6. Remote page rendering services
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)