User Acceptance Testing (UAT)
In this blog Helen Spry our Head of QA & Resourcing explores User Acceptance Testing (UAT) and highlights the importance of involving all parties. Be sure to never say UAT testing around her, it is definitely a pet peeve (the T in UAT already has the word testing covered).
What is User Acceptance Testing (UAT)?
This is the crucial last stage, looking at the functionality and making sure that it fits the purpose of the people who will be using the software daily. It is to prove the software can handle real life scenarios, performed by users. This stage must occur before the new developed software is released out to the market.
When should you start this process?
The UAT process occurs when the software development is largely feature-complete. It is different from system testing in that the software is still tested against functional requirements, but the test steps will follow the business processes.
Who should be involved in User Acceptance Testing?
Ideally, the end-users should be involved throughout the software development process but often they have their day job to do and will not be involved until the time has come to test. They might be aware of an exciting new life changing system coming to them, no doubt with an exciting project codename but beyond that, they’re just getting on with their jobs.
The business users are best placed to be involved. Anything can make that difference between a pass and a fail. From the order in which the users complete the fields, to whether they press enter or tab across from field to field. Even the smallest of things like inputting a date with no slashes and expecting the system to do the rest. It is these nuances that make user acceptance testing so vital.
Considerations for User Acceptance Testing
Scheduling UAT has to fit in with the users’ actual jobs. A delay in getting things out to test, can cause major problems with rescheduling and can reduce available time to test which may mean that the testing is not as thorough as hoped.
Another thing to consider, is that while the business users are experts in their fields, they are not professional testers. They know their jobs inside out but may need help with the niceties like writing and presenting the test scripts and raising bugs in a format with enough detail to help the developers fix it. Collaboration with the system testers is so worthwhile and should be encouraged in every project. Depending on the extent of their involvement in the project, this is the point at which it is not unusual to find that something very important to the end-users has not made its way to the end product – suddenly the excitement of having a shiny new system fade and that UAT becomes a chore.
It’s super important to have this process to reduce the likelihood of issues being raised which in turn reduces work required with maintenance and development.
So, to recap…
- NEVER call it UAT testing
- Involve the end-users as early as possible
- Get the system testers and users together
- Get it to the testers on time