Our Blog

Web Development Challenge – Testing Responsive Websites

The proliferation of mobile devices has been a boon to web development. The huge demand for responsive websites that display seamlessly across all devices (PCs, smart phones and tablets), has kept many a developer happily engrossed in their work.

The flip side to this demand however, is the amount of time it takes to test every responsive website. Web development is so much more than just creating an aesthetically pleasing design that is also functional.

Responsive websites must be tested across all browsers to ensure that they are indeed responsive. A few years ago, this wasn’t too much of a problem. There were only a few browsers around and so testing and supporting responsive websites was just part of the day to day job.

How web development has changed

The job hasn’t changed, but the amount of browsers has increased immensely, with at last count 80 browsers in use worldwide and more created all the time.

You can imagine that testing a single responsive website across 80 browsers (and all combinations of browsers, devices and operating systems) and providing support across these browsers, adds an enormous amount of time to a developer’s workload. In fact, the whole process becomes unworkable and practically grinds to a halt.

The expense of all of this additional work cannot be underestimated. The financial costs to support such a testing endeavour would simply be too expensive for any organisation.

Testing responsive websites

The answer is to be judicious in the number of configurations which are tested. For example, if the JavaScript works in one of the major browsers, we can reasonably expect it to work across the other commonly used browsers.

Similarly, if the code works on a Samsung Galaxy S model, then it will most likely work on Android tablets. Expecting a responsive design to work flawlessly across all browsers and devices however, is too big a stretch.

Trying to shove the genie back in the bottle can be a monumental task, but one trick is to use a tracker, for example Google Analytics to help identify which browsers, operating systems and devices people use to access a particular website.

Then you can create priority groups of browsers for testing, test the first group, launch the website and test the remaining groups later. Any errors found with the remaining groups of browsers, can be fixed and rolled out.

This strategy works well if you are only making minor changes and the responsive design needs to be released fairly quickly. If you are in the midst of a complete overall however, then you really should test all browser groups before launch.

Tips for testing responsive websites

Knowing your audience can help identify and prioritise your initial test groups. For example, older people tend to access the internet using a PC, whereas younger people use a range of mobile devices. So if your product is aimed at younger people, testing across all mobile devices is a priority.

Also be aware of the types of phones that are popular in different geographic areas. If your audience is mainly in the East, then know that they like phones with large screens (phablets) and include these in your tests.

Also, in your first batch of tests make sure you include as many screen sizes and connection speeds as possible, as well as pixel densities and interaction styles (touch, mouse, keyboards and D-pads).

Don’t forget to include proxy rendering in your tests as even though this is a niche market (Chrome mobile and Nokia’s Ovi browsers use proxy rendering), responsive websites are likely to need tweaking to display correctly on browsers using proxy rendering, rather than a typical web browser.

A way forward in testing responsive websites

You have two real options for testing responsive websites – automated or manual testing. Automated testing is good for finding out what works, whereas manual testing is better for finding out what doesn’t work and why.

So there needs to be a balance between these two methods; obviously manual testing is superior to automated testing.

A suggestion is to set up 3 groups for testing, with the most common devices and browsers in the first group (generally about 50% of the audience). In the second group test mainly desktop browsers and in the third, include the proxy browsers.

The cost of buying multiple devices to use in these testing strategies is not small. The best advice is to maximise your time by knowing your audience and prioritizing your testing procedures.

If you have any other testing ideas or strategies, let us know at info@cornerstone-digital.com.au.

• Comments (0)
• Trackbacks (0)
• Permalink

Jason Lopez

Jason is a Web Developer at Cornerstone who appreciates building websites that delight and inform. He is a curious person, and enjoys work that challenges him to learn something new and stretch in a different direction.