The human experience

building brand value through data-driven marketing

Since 1996, we've helped leading brands create interactive customer experiences that drive measurable business value.

The swashbuckling game of browser testing

By Mike Moss • October 26, 2012

Browser testing is one of the unsung heroes of web production. It’s not sexy, it’s time consuming, and when its results are put to good use, it is completely transparent to the end user. It’s kind of like the invisible swordsman standing behind Zorro, doing all the buckling while Zorro focuses on the swash. (Also, please assume for a moment that there is an invisible swordsman behind Zorro, and that “swash” is a noun.)

It should be relatively straightforward: you want to make sure that your web page or email looks the same to everyone who views it. Simple, right? The problem, and you’ll have to pardon the technical jargon here, is that there are a lot of browsers. There are as many email clients. They all use different standards to render HTML, which reduces your chances of universal cross-browser compatibility to nearly zero. They also support different features based on which version of a browser is being used, which multiplies the variants available to cyclopean proportions.

Compounding the issue is the fact that QA budgets are a finite thing. This is what separates them from, say, my desire for pumpkin pie, which is infinite.
A complicated and delicious diagram
(fig.1) You cannot afford to test in all browsers. I can eat an entire pumpkin pie.

So what browsers should you try to support, given limited resources and the myriad choices to consumers?

Look to your audience. It is very easy to just resort to testing in the Big 3 (IE, Firefox, Safari), but that doesn’t always mean it’s a perfect fit. Don’t apply an umbrella solution to all of your projects; you could end up wasting valuable QA time checking in browsers your customers will never touch. Find out what browsers/email clients the bulk of your customers are using, and focus your energies there.

Some questions to ask:

  • Is your audience primarily composed of Mac users (Safari/Firefox), or PC users (IE/Firefox)? (vs IE/Firefox)?
  • Are you targeting developers, software engineers, or other tech savvy groups that are generally skewed away from IE?
  • Where (work/home/public terminals) are your emails/web pages going to be viewed? (Work installations are usually weighted towards IE use.)
  • Are you targeting early adopters who always have the “latest and the greatest” installed on their machines (Google Chrome, etc)?

Dissecting your audience like this will help you hone in on a viable test plan even without the help of metrics. Besides, if we’re to believe the stats, testing in IE will cover most of the bases. But browser statistics, while helpful, do not tell the whole story. You have to know who you’re marketing to.

So until everyone on the planet is using the same hardware and software (my blog entry for that month: Browser Testing: Why?), there won’t be one, perfect testing solution, and no amount of dreaming, wishful-thinking, or praying to ancient, heathen gods will make it happen.

How I know that last part is irrelevant.

Just focus on the needs of your specific audience, and your browser testing efforts will pay off.

Leave a Reply

Your email address will not be published. Required fields are marked *