Making sure it works – testing the new London.gov.uk

25 November 2015

Last December, we asked Test Partners to help us test and quality assure City Hall’s new website. Mark Wilkinson, Test Manager, talks about the range of testing needed for a project like this and why it’s essential to make sure the end result is as reliable as it can be.

Testing software and websites is a challenge. We need to ensure that the final product is fit for purpose, and as good as it can possibly be. We must also understand it can never be totally free of bugs. We do lots of different types of testing from User Acceptance Testing (UAT) to performance and accessibility testing. All of this is essential to make sure that the final website does everything it’s supposed to do.

Exploratory testing

We start by making sure that the site’s functionality meets a pre-agreed set of formal acceptance criteria. We then take a critical look at the site to check that anything not covered by the criteria is tested too. To do this, our testers use a technique called ‘exploratory testing’. It means relying on the tester’s skill and experience to ensure coverage – as opposed to running through pre-written scripts. The reason is that these scripts may not cover all the functionality that has been developed. Over the course of the project, we’ve identified and fixed 1,500 bugs working this way.

Compatibility testing

We must also ensure that the end user has a good experience of browsing the site – whatever device they’re using. These days there are lots of different devices, operating systems and browsers. We test the site on everything from iPhones to Tablets, and of course, standard PCs, and make a note of anything that doesn’t work as it should. The new website has been created with a ‘responsive’ design. That means it quickly adapts to the viewing device without the need for separate sub-sites for mobile phones or tablets.

Accessibility testing

We check too that the website is usable for everyone who wants to use it. Some people may have disabilities that means they need special software (like screen-readers) to browse the web. This means we must design website that are easily accessible to these specialist tools. That means using code that is well-structured and meets the common accessibility standards. Our accessibility tester checks this using the same tools a typical end user might use.

Performance testing

Finally, a website can sometimes be the victim of its own success. As part of due diligence, we must test to see if the server and networks that host the website can cope with hundreds or even thousands of users at the same time. We do this by using special testing software which can replicate the effect of this number of people using the site simultaneously.

Why do we test the website?

By testing the website in the ways explained above we can create an end product that works for different users, different devices and different situations. It protects the site from harm while at the same time reducing time and reputation risk.

Another important aspect of testing the website as it develops is ‘usability testing’ where we ask invite end users to test new designs or functionality of the website. We’ll be writing more about this part of testing in a future blog post.