Top 5 Reasons To Test Your Website Across Browsers

I would hope that those of you taking the time to read this posting would have some idea of why you should perform some level of testing of the software and websites you create. However, I am keenly aware that some management types don’t always understand the importance of testing until an untested “feature” appears in the wild, frustrating all that run across it.

  1. Ensure Cross Browser Compatibility- Unless you develop a website for internal usage only, where you are able to successfully restrict users to a specific version of a specific browser, Cross Browser Compatibility ensures your site functions well for the greatest number of users.
  2. Detect Shallow Errors - Simply loading a website for a quick look in all the major browsers allows you to find 95% of all the browser compatibility errors for your site.
  3. Discover Performance Issues - Typically, older and less-advanced browsers, such as Internet Exporer, and the older versions of Chrome, Firefox, and Safari are unable to process the CSS, JavaScript, and HTML that the most recent and more-advanced versions of these browsers handle with ease.
  4. Prioritize Backwards Compatibility - I have heard countless times that we need to make sure this website supports browser versions that were released more than a decade ago. Instead of just making excuses for why you can’t support them, testing your site in the older browsers first allows you to put a more accurate time estimate that supporting these browsers will require. Its amazing to see how the requirements for supporting old and outdated browsers evaporate as the time and cost estimates begin to add up.
  5. CYA - Whether it is your internal customer that is requesting the new website or you are an agency working with another individual or business for a new website, the last thing you want to have happen is that the customer open the site when it goes live in a browser you have not tested yet and has major issues. Establish ahead of time what the list of supported browsers will be and make sure to test all of them. If you have time, test the next most popular browsers or versions of popular browsers.

While testing your website may not be the most exciting part of web development, it definitely will save you time and money in the long run.

Related Posts

May 21, 2014
One minute

Window.Open Causes Browser Compatibilty Issues

One of the things that always annoys me as a web developer is when native browser functions that are accesible from JavaScript do not share the same function signature. One perfect example of this is the window.open function. When you are using non-Microsoft browsers such as Firefox and Chrome, you are able to make a call something like this window.open(url, 'window name', 'dimensions or other settings');. The window name parameter is important because it allows you to open multiple links in the same external window/tab. However, when using Internet Explorer, especially Internet Explorer 8 and older, you can only use window.open(url);. If you try to use the first type of function call, you get a very ambiguous error message in the browser that doesn’t tend to show exactly where the error occurred.

Jan 8, 2015
3 minutes

Write Bulletproof JavaScript

While display issues have long been the bane of a web developer’s existence, current web development projects tend to have much more client side interactivity, focusing ever more attention on the reliability and resilience of the JavaScript you write to deliver the complete interactive experience. Many things can cause unexpected errors in your carefully crafted code.

However, there are a few things that you can do to make sure that your site degrades gracefully and still provides a basic level of functionality when something in the browser goes wrong. The following snippet of code illustrates a few best-practices for defining your JavaScript namespaced modules.

Jul 16, 2014
2 minutes

Write Software for People, Not Computers

Throughout a normal day, I end up reading a lot of information about current issues in technology, and today is no different. There was a debate raging about whether or not high-level math was required for programmers that was sparked by this article by Sarah Mei Programming is not math. While it is an interesting topic, and, surprisingly, I mostly agree with Sarah on this issue, that is not the most important portion of her post. The important part is instead a quote from Structure and Interpretation of Computer Programs from MIT Press, and is as follows: