In building mobile sites, you simply cannot optimize for every
device/browser/OS out there. So before you can think about a test plan,
have your client pick their top 5 browsers/OS configurations and screen
sizes — based on their scope, product, audience and locale — and shoot
to optimize for those. Just like regular browsers, there will still be
minor differences here and there.
Help your client narrow down mobile browser/OS configs:
1. Start by viewing their mobile analytics, of course.
2. Determine the scope of their mobile offerings, as well as their
audience and locale.
3. Check out DeviceAtlas.
Navigate deeper to see specs on each device, such as operating system,
screen size, color depth, etc.
4. What are the top mobile configurations, you ask? Well it largely
depends on locale, what’s new, etc. etc. They change frequently, but
here’s a relatively current list of Top 10 selling smart phones spanning more than six
continents and 50 countries.
The testing side:
Note that a good bit of testing can be done without an emulator or
mobile device. Depending on the scope of the site, of course, it is
possible to do most of your functionality testing on a full-size
browser. Then move to the mobile to focus on design elements/rendering,
formatting, usability. Don’t forget to check both portrait and landscape
modes.
1. Before writing your test plan, familiarize yourself with W3C Mobile Web
Best Practices and Mobile Web App Best
Practices. These are looooong, I know. But at least skim them to get
a feel for some of the high-level best-practices. (At some point, I
want to take a stab at whittling those docs down for a quick-hit view.)
2. On a full-size browser:
- As far as running automated tests, such as checking links, you can
run your normal link validator. I use Web Link
Validator and InSite.
- As usual, enable your JavaScript error notifications.
- Use your regular tools for validating analytics as well as dev and
design elements (though not necessarily browser formatting): dev
toolbars, Fiddler, Firebug, etc.
- Test your site for mobile readiness: Visit mobiReady
or W3C and plug
in your URL or file (on W3C) and go. They list errors in order of
severity, error location and best practices around each error. Both are
very user friendly. mobiReady even spits out estimated speed on WiFi,
3G, GPRS (what about EDGE?).
3. Emulators: I recommend the actual hardware if you can get your
hands on it, even if you have to ask people around the office to use
their mobile for a while. If you must use an emulator, I’d start by
simply searching for emulators on the product maker’s website. i.e. Go
to Apple and search for iPhone emulators. Here are some links to emulators by manufacturer. As a last resort, there
are generic emulators aplenty out there.
I haven’t done this yet, so I can’t really speak to it … but it looks
interesting, and I intend on giving it a go. Test mobile sites using Firefox extensions.
Finally, remember that mobile sites are often a very pared down
version of the full site, for good reason. Utilize user agent sniffers
to determine if the user should be auto-directed to the mobile site, but
always give them the option to view the complete site in case that’s
what they prefer.