How to QA your website

By Farrell Coleman, 2nd September 2015

So you’ve opened your new shiny website, scrolled through your professionally structured content and your beautiful parallaxing imagery, and all is well; time to go live! But hang on a minute, when I scroll to the bottom of the page the navigation bar flickers and disappears…that wasn’t part of the original designs. Also, I don’t remember my contact email address being [email protected]… Something isn’t right here.

Whether you built your website yourself, hired a freelancer, or went professional with a web design agency, QA’ing (quality assuring) your own website is essential. In fact, setting aside some time to thoroughly investigate each page is just as important as adding the content or signing off the designs.

This guide will highlight five important rules you might not have considered when testing your website.

Rule 1: Understand your audience

The importance of understanding your audience is strong in most fields of web design and development, and QA is no different. If you have a current website you’re planning to replace, have a look through its Google Analytics (if you don’t have Google Analytics, get it now!) and look for any noticeable trends in or around browsers and operating systems.

What percentage of your users are viewing the site from mobile? Why are 10% of your viewers coming from Internet Explorer 7? Does your site attract a lot of traffic from an older demographic? These are all great questions to ask at any stage of commissioning a website but they are imperative when testing. This is because extensive efforts are required to make a website backwards compatible with IE7, add triple A accreditation, or make sure it’s screen reader ready, and the reality is that not all of these things are necessary for every website.
Understanding your audience can help you make the important decisions of what to keep and what to scrap early on, so that when your website goes live, you don’t become inundated with users complaining that the site doesn’t work on their Windows 98 Packard Bell running IE6, or older users stating the font is too small and sizing it up causes the website to crop.

Rule 2: Emulators are not always reliable

You’ve commissioned a mobile responsive website and you have a hunch that it will be popular with the shrinking Blackberry crowd. You want to see how it is going to look but you don’t want to go out and buy a Blackberry, after all, you just bought a new iPhone. After a quick Google search you find a mobile emulator a little like this one. Oh no! The website falls to pieces at Blackberry resolutions in their native browser and you are due to go live in a week.

It could very well be that your website does fall apart in a Blackberry emulator, but take it from someone who has spent a great deal of time arguing with developers who are unable to recreate bugs found on an emulator: it is just as likely to be the emulator that is breaking the site as it is that the site is the problem.

If you report these issues to your developers or your design agency and they can’t recreate them, bite the bullet and buy the Blackberry. It’s a win-win because, if the issues are there you can show the developers and get the problems resolved, and if they’re not then you know your website is working as intended!

Rule 3: Cross browser testing is really important

Testing is dull, especially manual testing. Clicking every link on a page and scrutinising every pixel is likely to drive you insane before you’re done with Google Chrome alone, particularly if your site is a vast E-Commerce virtual warehouse. It’s very easy to get to the end of this task and be ready to call it a day, thinking “It worked fine in Chrome, I’m sure it works fine in Firefox too.” Unfortunately, this approach to website testing is useless.

Your website could work perfectly fine in Google Chrome, with all your fancy animations displaying on load, and your calendars and date pickers flashing invitingly on mouse over. However, when you open it in Safari it looks like someone sneezed a website onto the screen. If a developer builds specifically for one environment, you’d be surprised just how much it can break on the others.

Rule 4: Understand where to draw the line

If you happen to work in the healthcare sector or the education sector and your clientele include government contacts that can’t update their browser past IE7, then there is a strong cause for needing this level of support. However, if you sell luxury yachts to millionaires then raising hundreds of bug reports for issues in browsers from the early noughties is probably just a waste of your time and budget.

The same principle can be applied to cosmetic fixes on more mainstream browsers. Whenever you document a bug it is worth stopping and thinking, “Is anyone likely to see this?” and then you can prioritise accordingly. By all means, fix everything you have the time for, but if you’re on a tight schedule the last thing you want is your developers obsessing over an image that is displaying one pixel to the right on some old versions of Android when the contact form currently explodes if your name has an F in it. Knowing what bugs are important and what can be fixed post ‘Go Live’ can be the difference between a delayed project and a project successfully launching on time.

If you’re highly invested in the website it is easy to think that every issue is an essential pre ‘Go Live’ issue. A good way to escape this mind set is to go look at some of the sites you usually frequent such as your online bank, your supermarket, or even the likes of Facebook and Twitter, and you’ll see how many small cosmetic issues you can spot that you otherwise would never have noticed.

The point is that your average user is far more disconnected from your website then you are and is almost definitely not going to notice that one product image has a 2 pixel left hand border whilst another completely unrelated product has a ridiculous 3 pixel border! Should you care? Definitely. Should everyone down tools and beat up the developers until it is resolved? Probably not.

Rule 5: Retest everything!

So you have been through your whole site on every browser in ten different resolutions. You’ve tested on iPad and Samsung Galaxy Tab. You purchased a Blackberry and a Nokia Lumia. You even went all out on a ridiculously expensive screen reader that is only ever going to be used for testing. You listed your hundred highest priority bugs and went through them one by one with the developers who in turn tutted and sighed but eventually yielded to your testing prowess. Job done! Enjoy a nice glass of wine or three and put your feet up.

Except this is just the beginning, as once your developers are finished making their changes and fixing your existing bugs, it’s time to start again! This is not an insult to developers – it is just the reality of the situation. Nobody is perfect, and depending on the complexity and scale of your website, there are likely to be a lot of moving intertwined parts so there’s no guarantee that changing one won’t have a knock-on effect on another. Retesting, or regression testing as it is often referred to in the industry, is the tedious but necessary practice of checking and double-checking every fix and anything it could feasibly affect.

There is a lot more we could discuss, as unfortunately, these five measures don’t even come close to covering everything that QA’ing your website should encompass, but following the rules we’ve listed should help make the process a little bit less painful and slightly more structured.

Alternatively, if reading this article has made you dread the prospect of dutifully testing your website down to the smallest pixel then you could always use a web design agency with an in-house team of dedicated testers who relish the opportunity to poke holes in the work of their development team, ensuring only the best work makes it to a client’s screen.

If only we knew where to find such an agency