There are a growing number of browsers entering the market (including those for tablet and mobile devices) which means your website under test needs to be working well for your supported browsers.
The existing mainstream browsers (Internet Explorer, Firefox, Chrome, Opera, Safari) are also updating themselves very frequently and often without the end user being aware of the update.
This makes testing against this growing number of browsers essential but also increasingly more time consuming.
As with all testing though, ensure you check what is supported and what isn’t by your own product/company. One of the most successful ways to reduce browser testing is to stop supporting older browsers. This is a good strategy for some companies, but not possible for all.
It obviously doesn’t make these old browsers bug free (or even guaranteed to work) but it does mean you can ignore potential problems with these older versions and focus on the version you actively support.
Spread The Risk
One approach could be to run your everyday tests against a mixture of browser environments.
For example, you may be testing a simple web application where the user can log in, generate some reports, send the reports and then log out. The system also has a simple “management” system where sys admins or managers can view who is changing what.
To get a wider coverage you could test your log on functionality in one browser, test the send report functionality in another browser and then the audit trail functionality using a third browser.
This is an effective way of covering different combinations of browsers at the same time as doing your day-to-day testing. The above example won’t highlight a bug with the audit trail functionality in the first and second browser though. So there are plenty of gaps for bugs to slip through, however the time it saves may make this a good option.
Let someone else do it
For appearance issues there are many online tools like Browser Shots, which will load your page in any of the supported browsers (they support a great many versions), take a screen shot and then make these screen shots available to you.
This is great for websites, but applications that require credentials or have a huge number of pages are somewhat more difficult. It will also only check for look and feel issues.
The Browser Shots homepage
Check against standards
You could validate your site against an HTML standards checker. Checking against HTML standards will give you more confidence the site works across many browsers, but there are still some browsers that will render pages differently.
A good standards checker is at the W3.org page.
You could automate your checking using something like Selenium, and then use a tool like Selenium Grid to test against several browsers.
This has infrastructure requirements and is obviously reliant on an automation suite existing (or going to be brought in to existence).
It will also only check what you have told it to check.
Automated checks are great for functionality but will not tell you about layout issues between browsers.
Fight Layout Bugs
You could write some automated tests to check the layout issues your site may face in different browsers.
Fighting Layout Bugs is an open source Java project providing an automated way of checking for potential layout bugs. As it’s Open Source you can add back to the project.
Manually Test It
You could manually test against each version by installing all of the browser versions on different machines. To make this less of a chore it would be worthwhile using Virtual Machines.
These can then be cloned and re-used by others, or centralized somewhere for multiple users to access. This too relies on infrastructure.
It also requires significant time and effort from a Tester, but gives you the human analysis of cross browser compliance.
You could narrow the browsers down to engines.
Chrome and Safari use WebKit. Firefox uses Gecko. Internet Explorer uses the Trident rendering engine. Opera uses the Presto rendering engine.
You could therefore “assume” that testing on Chrome will cover off Safari. This may be an assumption too far for many though.
You could use tools that attempt to emulate the different browsers. There are a number of tools on the market, as well as some inbuilt tools within the browsers themselves to render older versions.
A few words of caution though, they are not wholly accurate in my experience, but they *may* provide insights that are useful.
If you have a suite of Selenium tests but do not have the infrastructure or experience in house to get a grid up and running then you might find services like Sauce Labs and Testing Bot quite useful.
I’ve not even touched on different operating systems or mobile devices but as you can see there are a number of ways to approach the cross browser issues.
Cross browser support may be your biggest pain-point, especially with the rapid rate of release that most of the browser companies are now adopting.
In my experience a nice selection of a number of the above works well.
Some browsers come with compatibility modes, which allow you to emulate different versions.
Some browsers, like Chrome, have developer tools for rendering pages in different browser and Operating Systems.
Compatibility Mode page on Wikipedia – http://en.wikipedia.org/wiki/Compatibility_mode_(software)
IE9 Browser Compatibility article – http://blogs.msdn.com/b/ie/archive/2010/10/19/testing-sites-with-browser-mode-vs-doc-mode.aspx
Sauce Labs – http://saucelabs.com/
Testing Bot – http://testingbot.com/
Browsers and Rendering Engines – http://en.wikipedia.org/wiki/Web_browser_engine
Selenium Grid – http://selenium-grid.seleniumhq.org/
Standards Checker – http://validator.w3.org/
If you want to talk Testing – catch me later this year at EuroSTAR conference.