Website Testing Process
When designing and building websites, any professional will tell you that you should test in as many browsers as possible. In the real world, the number you can actually test in may be quite small, depending on your operating system and how many computers you have access to, but you can still set up a process that will allow you to feel reasonably confident that your site will look (almost) identical for the vast majority of your site’s visitors.
In this article I will take you through my own browser compatibility testing process, which uses nothing more than a Windows XP notebook PC.
A quick word about my development process first: I don’t like to reinvent too many types of wheel, so I usually start with a standard CSS template. If I am building a 2-column site, I take and adapt a suitable template from Dynamic Drive, and if I am building a 3-column site I use a custom template of my own devising (the Dynamic Drive 3-column templates sometimes fail on Google Chrome).
I use Firefox as my main development browser; in other words, when I start to build a site, Firefox is the browser that has my new page open, and I refresh the page with each change I make. I have the Web Developer Extension installed (I find Firebug hard to get on with), and use it to check that my HTML and CSS are valid at each stage of the development process.
As soon as I have my basic layout in place, and then whenever I make CSS or HTML changes that affect the layout, this is when I fire up the rest of the browsers I have installed. For example, whenever I add any layout segment that uses floats, or add a navigation menu, or change the dimensions of any part of the layout. Anything more than adding a bit of content or changing a colour means that it’s time to do the testing tango, using the following browsers.
Chrome is increasing in popularity and, like Safari, uses the Webkit rendering engine. I very rarely find that a layout built in Firefox gives me any problems in Chrome (apart from some 3-column Dynamic Drive layouts as noted above – so I simply avoid using those). I keep my Chrome installation updated to the latest version, because that is the default behaviour, meaning that most other Chrome users will have the latest version as well.
So few of the visitors to my sites use Opera that I used to think “why bother?”. But conversely, the latest versions of Opera (9 and 10) cause so few problems when testing (none at all, so far!) that I decided I may as well include it in my testing suite, simply because it never causes me any hassle. I use the latest version of Opera, because people who have made the decision to use such an uncommon browser are probably sufficiently committed to it to keep their version up to date.
Safari uses the same Webkit rendering engine as Chrome, however it still manages to treat code differently at times, so it must be included when testing. Having said that, because I keep the fundamental structure of my layouts quite simple, it rarely causes any problems. Like Chrome, I use the latest version of Safari for Windows, because it auto-updates by default.
You’ll notice that I didn’t head this section “Internet Explorer“. That’s because I never actually launch Internet Explorer – ever. IETester is a freeware Windows application that allows you to open URLs in tabs like any browser, but each tab can behave as if it was either IE5.5, IE6, IE7 or IE8. It picks up where the now-abandoned Tredosoft Multiple IE application left off, and does it better. It even has a companion plugin called DebugBar which allows a limited amount of DOM-based debugging.
I never use the IE5.5 tab (I haven’t seen IE5.5 on any of my sites’ analytics for quite a while), but I do test my layouts in IE6, IE7 and IE8 using IETester. This means I can easily see where a transparent PNG image makes things look bad in IE6, and I can see where I have a “has layout” or “double float margin” problem in IE6 and IE7.
Note: I always set IE8 to IE7 compatibility mode in my sites’ headers, so in theory I shouldn’t need to test in an IE8 tab, but I take a quick look anyway because I don’t trust Microsoft.
Recently I mentioned IETester when answering a query on LinkedIn, and my comment got the following response from an experienced web professional in Israel, who will remain anonymous to spare her blushes:
“Andy, I can’t thank you enough for telling us about IETester. It’s a web developer’s dream come true. I shared it with others in our office and they literally had tears of joy in their eyes – that’s how bad working with IE is. So thanks for lowering our IE-related stress levels. This tool is a life saver.”
My only niggle with IETester is that it uses a horrible Office 2007-style ribbon in its UI, which grabs a huge amount of screen area, but this pales into insignificance in relation to the sheer usefulness of the application.
What Do I Actually Test?
If your site makes use of AJAX, you should also test all AJAX functionality on your entire browser testing suite.
The testing regime that I’ve described above, when I first put it in place, instantly put a stop to the “your site looks funny on my browser” emails that I used to get occasionally in my younger and less experienced days. It’s not perfect (I don’t own a Mac, so I can only test the Windows version of Safari), but it’s airtight enough for professional work.
Once in a blue moon someone will tell me that a site looks odd or breaks in something really obscure like Konqueror or K-Meleon. If I decide that it’s a big enough problem to try and solve, I use my old stand-by BrowserShots – but if it’s only cosmetic I don’t usually bother, for the sake of 1 visitor in 50,000.
If you are a web developer your testing regime may look a little different from mine – but the most important thing is that you have one that makes sense for you and your visitors, and that you apply it consistently and without fail.
If you don’t have a formal process that you follow, why not start with something like mine and adapt it as you go along?
I’d be really interested to know if you think I missed out something important, or if you have any tips which would improve my process. Comments are welcome – and don’t forget this is now a “dofollow” site.