Blog

Read articles written by our team here at Splice.
Call us on 0845 652 2412 to book a FREE consultation.

RSS

Testing Procedures for Websites

Wednesday, December 26, 2012   0 Comment(s)  

Every website needs testing, whether it is a brand new website, a new section of a website such as a user area or simply updating an existing section of a website.

There are many different methods and processes you can use for testing websites; both in terms of testing the code used to provide the required functionality and testing the functionality to ensure it works and is easy for the end user to accomplish their desired task. The five most common types of testing are detailed below. In order to explain them more easily I will be using the following scenario:

"You are building a module to provide a customer area on a clients’ e-commerce website. The area must be located behind a secure login area. It must provide the functionality which allows customers to view their previous orders and to update their personal details."

Unit Testing

Unit testing, as the name suggests, refers to testing a ‘unit’ of a much larger project. This may be as small as a contact form being added to a set of webpages or as large as adding a whole new section to a website, for example a user area hidden behind a secure login.

This type of testing is usually the first type of testing to take place. It is designed to catch any problems as early as possible. Every project can be broken down into smaller parts; unit testing aims to test each of these parts as they are written, to eliminate any potential bugs before the ‘unit’ is incorporated into the main project. If this testing does not take place then bugs may find their way into the larger, entire project, making them much harder to locate.

In our scenario unit examples would be:

  • Retrieving a set of previous orders for a particular customer
  • Logging into the secure customer area
  • The project itself is also considered to be a unit because it is a small part of a much larger project (the complete website). However, testing for this is covered by the ‘Full Testing’ section below.

Once the smaller units are assembled into the project you are building, unit testing should be performed on the entire module.

Unit testing mainly tests the code to ensure the correct results are obtained, rather than testing customer interfaces. It is measured by comparing the expected outcome of each test with the actual result.

Full Testing

Full testing is the testing procedures carried out on an entire project. This could be as small as the module considered above or as large as the entire website, or both. In practise, it is always best to consider performing full testing on both the module itself and then on the full website, once the module has been integrated.

The full testing should find bugs that are part of the module as well as any bugs that may be caused by interaction with other parts of the site. Such bugs caused when a unit is integrated into the website can often be overlooked and not even considered, prior to the integration of the unit. In some ways full testing is very similar to unit testing:

  • It tests the code which provides the functionality for the customer.
  • Some tests should be designed to ‘break’ the code, to make sure any potential errors, caused by customers interacting with the site or by hackers are correctly handled.
  • Whilst unit testing is always carried out prior to any integration, full testing is performed before and after integration.

Scenario Testing

Scenario testing is the final step of testing the functionality of a new module or website. As the name suggests it involves testing certain scenarios that may occur during the use of the website or module.

This is a necessary step, as a developer can be too close to a project and know how the module should be used, so they will tailor tests accordingly. However, a typical customer will not instinctively know how the developer intended the functionality to be used or even what to type into a certain box so they have a higher chance of “breaking” the functionality, even when they are trying to use the module properly.

Scenarios for testing can be typically obtained from the person who commissioned the project; they will have ideas about how they think their users will use the website. As a result they will be able to provide realistic examples of what they think their customer will be trying to achieve and how they go about it.

A typical scenario in our example would be for the customer to go the website, login to their personal customer area and update some of their personal details. This test directly relates to how a customer could use the module when left to their own devices.

Usability Testing

The aim of usability testing is to find out how easy or how difficult it is to achieve a set of goals on a website. This often comes out as a direct result of scenario testing, which highlights how easy (or more commonly, how hard) it is to achieve a task. Previously, this may not have been noticed with all the testing carried out by the developer, who already knew how to achieve the desired outcome without breaking anything.

The best way to perform usability testing is to find a person, or better yet a set of people, who have never seen the website before, give them a list of tasks (most likely the same scenarios used during scenario testing) and get them to give you feedback. It is possible to use special software to record testers’ websites use and comments enabling you to see (and keep a record of) their exact experience; where they got stuck and exactly they did to cause the errors.

These 4 testing types are all equally important and if followed correctly you will end up with a bug-free website that is also intuitive and very easy to use.

Comments (0)
Post has no comments.
Post a Comment

Captcha Image
Post a Comment

Captcha Image

0845 652 2412
Hampshire's Leading Conversion Specialist