UAT in Website Development

A vital part of any website development project for the business owner/marketing manager/brand manager is confirming that the vision they were sold originally has been developed in accordance with those requirements and designs. UAT is a vitally important phase that will provide that reassurance.

Website Development

Your development contract or statement of work should have documented what your developers will be building as well as how they will be internally testing and checking it. They should also have detailed the devices and operating systems they will test on as well. Following build, the developers will carry out SIT (Systems Integration Testing) and QA (Quality Assurance).

What is UAT?

UAT stands for User Acceptance Testing – an evaluation process that helps the stakeholder (you and your management) accept the website (or not) based on how it matches the brief/designs. It is your chance to see how it looks and works in what the developers would regard as a finished state.

This is a critical phase of the project and there is likely to be pressure from several sides to get to deployment as quickly as possible now that development has finished . Management will want the site to start driving sales or support campaigns, the developers will want to move their resources onto other projects and finish with yours. However, don’t be rushed – it is essential that you do a thorough UAT to ensure you get want you were sold. You’ll likely have to live with your website for several years, so invest the time now to resolve issues.

Whilst error correction should be covered under contract – changes that weren’t in the original scope will carry additional charge that you might not have budgeted for especially if there is design rework required.

Are SIT and UAT the same? No, SIT assesses how systems and sub-systems (such as modules, components or plugins) work and work together. UAT assesses whether the website meets the user/business needs when everything is brought together as a working website.

Structuring UAT

UAT should be a structured process with clear testing criteria and parameters. Just being given a development URL and told to “have a look round” is bad practice. You need to have a clear UAT plan that outlines how the website meets the need of the various stakeholder groups. This will detail entry/exit criteria as well as scenarios and test cases to focus your scrutiny.

This won’t just help you, it will also help the developers to be able to recreate the test condition you faced so they can fix the problem or error (including device, operating system and browser). If you don’t have a testing plan to document issues you can’t be sure you covered everything.

The UAT plan should cover all the features and functions of the website as per the functional specifications requested. You can then validate that they meet the needs of the users (both you as the business running the website and your customers as users).

Where possible it is good to use genuine users in UAT as they have no bias and will navigate according to their real requirements and behaviour. It will be real users that will find genuine issues once the website is deployed.

Example UAT Test Cases

There are hundreds of potential cases you could assess – document as many as you can and work with your developers to formalise the testing plan. Examples could include:

  • Can you add a product to the shopping cart
  • Is it possible to complete a transaction
  • Can you submit a contact form
  • Does faceted navigation work for product selection
  • Can you expand thumbnail product images to full versions
  • Does site search work correctly
  • Do carousels work as planned
  • Do concertinas expand/contract properly
  • Does your logo link to your homepage
  • Can you login if that is a feature
  • Can you request a forgotten password
  • Does the reset password email arrive

Documenting UAT Test Cases

Testing documentation could be an Excel file, better still would be a reporting tool such as Jira – this will allow multiple stakeholders and project personnel to collaborate and track issue through to closure. Regardless of the documenting option used, the following inputs should be present at a minimum:

  • Test number – a unique reference to identify this specific test by
  • Priority – is it classed as a high, medium or low priority
  • Tester – you or the colleague/user that will carry out the test
  • Platform – are you testing on a desktop, tablet or mobile device
  • OS – what is the operating system you are testing on (e.g. Windows 10 or iOS13)
  • Browser – what browser are you testing on (e.g. Safari and the specific version)
  • Date – when the tester carried out the test
  • Test name – a title for the test such as ‘internal site search validation’
  • Description – explanation of the test that will be conducted
  • Required inputs – such as any username/password/product selected the will be needed for the test
  • Test sequence – the individual steps for how the test should be carried out by the tester
  • Result expected – what should happen if the test is successful
  • Result experienced – what actually happened when the tester carried out the test
  • Pass/Fail status – confirmed by the tester as whether the expected matched the experienced or not

Following a structured UAT process will allow you to use your time efficiently and help the developers correct issues so you can retest and approve – then go live!