Testing Websites – Types of Testing

When you are trusting your entire company operations to a single website, it becomes the largest priority to keep it operating smoothly, efficiently and without any problems. Although there are not many companies that entire revenue stream is generated online, most modern companies will use their website to generate leads.

Making sure everything is running as it should be can be a daunting task; when there are over a thousand pages to test. However as the internet has grown and sites become larger and more important online so have the tools used to automate testing become more thorough and usable.

Tests in the programming world are separated into several areas, the main categories being:

Unit Testing
A system that tests each individual unit of the code separately to make sure it’s output is correct;    

Functional Testing
Functional testing allows the sites operations to be tested as if used by a customer; the system is “spoofed” into acting as it would when accessed by a real person and the output is tested against a set of rules it should follow.

Cross Browser Testing
Cross browser testing is the act of testing the sites design and layout in each browser to make sure it is visually similar to how it should be.

Unit Testing

When building large complex sites, it would be complex and costly to start from scratch with every project and build the groundwork from scratch; programmers have long learn’t that “re-inventing the wheel” is a pointless task which only increases the cost, amount of bugs and time needed to build a site. Instead, most programmers have a set of core tools and libraries which they use on every site; these are normally quite generic pieces of code that aid a developer in getting a site built quickly and smoothly.

Due to the way these units are used, it is the biggest priority that these units work exactly as they are supposed to; if a unit is found to have a bug in too late it can be on hundreds of sites that all would need upgrading manually. To stop this happening we use a “Unit Testing Framework” which allows us to write a set of expected outputs for a set of strict inputs, these are all manually worked out away from the program, e.g. in a library to work out VAT on products we would write a set of inputs (1 item at £5, 2 at £3, etc) and then manually work out the expected output and see if they match.

Although this may seem like a large amount of time to invest in such a small and simple module there is a huge amount of advantages; the main one being is if you change any of the code in the module you can simply re-run the test and make sure you haven’t broken anything. This can turn 1 hour of manual testing into a simple button click which an instantly tell is something has been broken.

A recent development in the “Agile Programming” area is Test Driven Development (TDD) this is nearly a complete reversal of the way code is written. In TDD a large number of tests are written that cover the whole purpose of the library and how it should perform; which code is then written against until it passes all tests.

Functional Testing

Although each unit has been tested individually and proven to have no bugs it is not surprising to find that integrating hundreds of these small units into a single site can sometimes have unexpected consequences. Functional testing can be used to help locate these problems and solve them correctly.

When the site is built (whether as a prototype or set live) a developer will go through the entire site manually testing each section of the site (search, re-ordering, contact forms, etc) and while this is happening, a tool (e.g. Selenium) will record all the actions that were taken to reach this point. This allows for the developer to re-run all these tests automatically in seconds whenever a new change has been made to the site; instantly allowing the developer to know if any parts of the site have been broken indirectly.

These tests can also be run on a regular schedule in the background to make sure nothing has been broken due to a time based error or change made by site owners; once a problem is found a developer is notified and the error can be fixed before anyone has noticed or any orders failed.

Cross Browser Testing

As the internet has evolved from a purely academic tool for research to a global point of communication for businesses and social reasons; the tools used to read and publish on the internet have changed. There are now more than 8 major browsers used to browse the web; each of these have different ways of handling text and layouts on web pages. Even though this can be seen as a small problem, it can sometimes have consequences larger than any programming bug; if the checkout button is invisible or hidden under an image in a browser such as Internet Explorer 6, then as many as up to 40% of the visitors will never be able to use the site.

Out of all the different types of testing that can be run on a website this is still the most manual; normally requiring someone to test each of the browsers on most pages manually. Luckily a websites’ layout and design will normally stay the same once set live and so only required to be tested once. However for websites that do change content frequently or theme the site (colours, banners, etc) for special occasions, there are a small set of tools that are now being used to help the automation of this testing.

Both Adobe Browser labs and Litmus Testing allow for a single URL to be submitted to the server which then fetches a screen-shot of the site in every major browser allowing them to be compared next to each other to find any problems.

Continuous Integration

When developing a site it is a major advantage to be able to know the instant something goes wrong before the problem is made any worse or data loss occurs. To solve this problem Continuous Integration can be used; it’s name is quite generic and can be applied to a variety of things however at Strawberrysoup, we use it to automatically run all tests required as we are writing code. This means that the second we need it tested, we already have the results and know where the problem is and when it was caused; allowing smooth development of highly complex websites.