What is UAT in software development?

The key points

• UAT is done by the client's users, not by the developer's testers.
• It checks that the software fits the business process, not only that it works without errors.
• Agree before it starts what counts as a defect and what counts as a change request.
• Sign-off after UAT usually triggers launch, handover and the final payment.

What is UAT in software development?

User acceptance testing is the stage where the people who will actually use the software check it against the job it was built to do. The ISTQB glossary describes acceptance testing as testing carried out to decide whether to accept a system, which is why the word acceptance matters: at the end, somebody says yes or no.

It differs from the developer's own testing. The development team tests whether the software is correct: calculations are right, pages load, nothing crashes. UAT asks a different question: can a receptionist book an appointment in under a minute, and does the report show what the owner needs on Monday morning? Software can pass the first kind of test and still fail the second.

Who does UAT, the client or the developer?

The client does it. Your own staff, or a few representative customers, run through real tasks with test data. The developer prepares the test version, supplies a short guide, answers questions and fixes what is found, but does not decide whether it is accepted.

Pick testers who do the work every day, not only managers. A person who processes thirty orders a day will notice that a button is in the wrong place long before a person who has never used the old system. Name one person on your side who collects findings and speaks for the group, so the developer receives a single list instead of ten emails.

How is UAT different from QA testing?

Quality assurance testing is the developer's side of the work. It covers whether each feature behaves as specified, whether the software holds up under normal use and whether obvious security and data problems have been checked. UAT comes after it and uses real scenarios from your business.

A simple way to remember it: QA asks whether the software was built correctly, and UAT asks whether the right software was built. Skipping UAT means the first people to find that mismatch are your customers.

What should a UAT plan include?

A short written plan keeps the stage from turning into an argument. It should name the testers, the dates and the test environment, which is a copy of the software with test data and never your live system. It should list the scenarios to be tried, written as ordinary tasks such as create an order, refund it and find it in the report.

It should also state the acceptance criteria, meaning the conditions under which you will accept the software. These come from the original scope, so the proposal for your custom software and the list of features agreed at the start are the reference. Finally, it should explain how findings are reported and how quickly they will be handled.

• The testers, the dates and the test environment
• Scenarios written as everyday tasks
• Acceptance criteria taken from the agreed scope
• How issues are logged, prioritised and answered
• Who signs off, and what sign-off triggers

How long should UAT take?

It depends on the size of the system. For a small first product it can be a few days of focused testing, and for a larger system with several user roles it can take a couple of weeks, with fixes in between. Fit it into the plan from the start, because testing is the stage that is squeezed first when a build runs late. The overall shape of a project is covered in our guide to the software development life cycle, and the time a first product needs is explained in how long it takes to build an MVP.

Run it in rounds. Test, send the list, let the developer fix, then retest what changed. One long round at the end tends to find too much at once.

What happens when UAT finds a bug?

Findings fall into three groups, and agreeing the groups beforehand prevents most disputes. A defect is something that does not work as agreed, and the developer fixes it as part of the project. A change request is something that works as specified but that you now want done differently, and it is priced and scheduled separately. A suggestion is a good idea for a later version.

Ask for each finding to be recorded with the steps to repeat it, a screenshot if possible and how serious it is. Serious issues, such as wrong totals or users seeing each other's data, are fixed before launch. Minor cosmetic points can be scheduled for after.

What does sign-off mean for payment and handover?

Sign-off is your written statement that the software meets the agreed criteria. It is normally the trigger for launch, the final payment and the start of the support period, so read what you are signing and do not give it under time pressure. If you want to compare how vendors treat this, our guide to comparing software development quotes shows where payment milestones and acceptance terms usually appear.

Before signing, confirm that the code, hosting and third-party accounts are registered to you, as covered in who owns your website after a developer builds it. Sign-off is also the point at which the developer's responsibility for fixing defects changes into a support arrangement, so check how long that support runs and what it includes.