How to run UAT on a new website build
What is UAT?
User acceptance testing (UAT) is an essential part of website development. It’s how you make sure that at the end of a project, you’ve built the right thing*.
It’s not the same as QA (quality assurance) but it’s just as important. Whereas QA ensures that the software is robust and bug-free (well, within reason!), UAT ensures that the product itself is providing the expected solution against the scope of work.
It is also not to be confused with user testing, which should be happening during the lifecycle of the project. User testing helps to ensure that the product is being designed and built with the key users at the heart of it, and is not typically used to find bugs, check requirements or test against back end processes and integrations..
Why should I do UAT?
It seems obvious to say you should run user acceptance testing on a new product, like a website or online tool. But for charities and not for profit organisations budgets are usually tight, timelines even tighter, and resources are stretched thin, so UAT can sometimes feel like a bit of a luxury. It’s not a quick, easy task to tick off, and in the run up to a launch it can get squeezed and deprioritised. That’s why it’s important to factor time in for UAT when you’re planning the project, not scrabbling around at the end to try and put a few test donations through.
There’s no perfect way to run UAT — you have to be realistic with the time and resources you have. But it’s better to have some in place than nothing at all.
The digital agency you’re working with should be able to advise you on best practices for UAT and perhaps start you off, if you’re not sure how to get going. But typically it’s better if you do the testing yourself, rather than the people who built the product — you’re closer to your users, you know what you need the site to do, and it’s much easier to test someone else’s work than your own. The developers who wrote the code for your product will have done QA in the form of peer reviews, but when it comes to testing the usability of the product, you’re best placed to do this.
This kind of testing will also help to expose any weaknesses across browsers and devices — you might have been looking at this new site on Chrome using a Macbook, so how will you know the site works well and looks good on Edge using an Android smartphone?
What’s included in UAT?
I find one of the easiest ways to set up a UAT process on a project is to look over the scope of work and pull out the key functionality as a first step. “Donations” might be listed as a very top level item, for example. You’ll need a spreadsheet, your scope of work, and a large cup of coffee.
Start by breaking down those top level pieces of functionality — user stories can be really helpful for this. You might already have your user stories written from the discovery phase of the project, but if not, try writing some down now to help you hone in on the journeys your users will take.
For example, “as a supporter, I want to donate a single gift using my credit card”. That’s a very basic story, but it can get the ball rolling.
So let’s break that down into your spreadsheet. Actually what this user wants is probably a bit more complex than just “make a donation”:
- I want to find a way to donate a single gift
- I want to choose the amount I donate
- I want to fill in my details using a secure form
- I want to opt in to / out of Gift Aid
- I want to see a confirmation page
- I want to receive an email receipt detailing my donation
You should plan to test this one simple journey multiple times, across different browser and device combinations. You’ll also want to stress test this journey — in other words, try to break it to ensure that it has the appropriate safeguards in place. Can you submit the form without completing mandatory fields? Can you submit an amount that is too high or too low? Can you use an email address that isn’t the right format? You want to find the bugs so that your users don’t.
Don’t forget to include test credit/debit card and bank details for testing single and recurring donations. If you’re also testing payment providers like Paypal you’ll also need to get test details for that. Ask the developers if things like emails have been deactivated on the staging site, so you know not to expect to see email receipts coming through, for example.
Are there any QA tools I can use?
There are some useful tools available to help you run your testing, such as Bugherd and Toybox, which allows you to drop feedback directly onto the site which gives your developers the context they need to recreate the issue. However, keeping a spreadsheet with notes is the best way I’ve found of testing dynamic pieces such as forms. Have a clear “pass” and “fail” threshold so you can easily spot the issues which need to be sent to your web agency.
Here’s a handy template to get you started.
*If your agency/supplier has run a good process, you won’t be seeing this product for the first time at the end of the project. But being able to test end to end is, in my opinion, the most efficient way to do user acceptance testing — you avoid testing something that isn’t quite finished.
