Policy on supporting multiple browser versions

Time travel back 15 years.
I recently had a conversation with an IT product manager that wanted to post a statement on a website about which browsers are officially supported by the site. There was some angst with the testing group as well as the technical support desk about phone calls from customers that had browsers that were recently released. It gave me flash backs to the early days of the internet when I would see statements on websites like:

“This site works with …..”
“The site requires …..”
“This site is designed to work with….”

I know it’s not possible to test with every combination of browser version and operating system.
The root of the request was that the quality assurance group was not setup to test with every browser version. I get that. Unlike the early days of the internet, there are more options than Internet Explorer and Netscape. Plus add years of build-up and internet browsers now have multiple versions in the market. But this problem isn’t unique to my colleague’s products. It’s part of doing business on the internet.

What customers expect.
Customers expect your internet site to work. Whether they are shopping, price comparing, or researching product information, they expect to find information and not think about their choice of browser. Most of my friends (non-technical) don’t think about Chrome, Firefox, Internet Explorer, Opera, Safari, etc. Most of them use the browser that was installed with their system (Internet Explorer usually) and don’t even know the version number installed on their system. Their expectation is that they can transact with information without thinking about the tool.

A Better Way.
I recommend to look at your internet analytics to see what the most common browsers are for your customer base. Pick the top two or three and make sure the QA group tests with those browsers. Make sure the developers are programming with industry standard techniques and then handle incidents on a case-by-case basis. This type of approach will minimize the number of issues and not alienate any of your customers that have chosen a different browser from what is officially tested.

Make sure the technical support staff collect the browser type and version on incident calls. Issues may or may not be related to the browser. But this gives your organization a better chance of replicating issues and determining if the root cause is related to the browser.

When you know about a browser incompatibility.
If you determine there is an issue with a particular browser type and version then do two things:
1. Notify the technical support staff so that they can inform and customers experiencing this issue.
2. Determine if you need to resolve the issue. The answer is determined based on many factors such as:

  • Is it a complete block in the order flow?
  • Is there a suitable work-around for the customer?
  • How common is the browser type and version the customer is using?

A good example in 2011 is the continued use of Internet Explorer v6. The browser is now ten years old and does not support many of the programming features of the internet today. In a B2C environment it may be easier to walk the customer through an upgrade. In a B2B environment this may be more complicated depending on the number of installations and compatibility with other software.

The Big Idea.
The big idea though is to have a policy that states it’s your intention to support all browser types and versions. Really, this is an unwritten policy that is expected by internet customers. You can test with the most common versions and then examine issues as they arise and treat them on a case-by-case basis.