User acceptance testing is the final testing stage of a software project, carried out by the client's own users rather than the developers. It confirms the software does what the business actually needs against agreed acceptance criteria, before the work is formally accepted and paid for.
What UAT is and why it matters
User acceptance testing, almost always shortened to UAT, is the last gate a piece of custom software passes through before you accept it. It is the point where your own people sit down with the finished system and check it does the job it was commissioned to do.
For a buyer, UAT is the single most important checkpoint in the whole project. Everything before it is the supplier's work and the supplier's judgement. UAT is your work and your judgement: it is the moment you decide, on the evidence in front of you, whether the software is fit to accept and pay for.
Skipping it or rushing it is a costly mistake. Once you have signed off, problems become harder and slower to put right, and you have far less leverage to get them fixed.
What UAT involves in practice
UAT is not a quick glance over a demo. It is a structured exercise where real users work through real tasks. In practice it usually involves the following:
- Test scenarios: a written list of the everyday jobs the software must support, often drawn from the agreed acceptance criteria.
- Hands-on use: your staff carry out those scenarios themselves, in conditions as close to normal working as possible.
- Recording results: each scenario is marked as passed or failed, with clear notes on anything that does not behave as expected.
- Fixes and retesting: the supplier corrects what failed, and the affected areas are tested again until they pass.
UAT belongs near the end of the software development lifecycle, after the build and the supplier's own testing are complete. It is the last stage of software testing before go-live.
How UAT differs from the supplier's QA testing
A good supplier tests its own work thoroughly before UAT ever begins. That work is quality assurance, or QA: the developers and testers check the software is built correctly and find the bugs. UAT is a different kind of test, done by different people, asking a different question.
QA asks "does the software work as we built it?" UAT asks "does the software do what the business needs?" The International Software Testing Qualifications Board, the global testing standards body, treats acceptance testing as a distinct level whose purpose is to establish confidence and readiness for use, separate from the supplier's earlier testing.
The reason both are needed is simple: software can be flawless against its technical specification and still be wrong for the way your business actually works. QA cannot catch that. Only your own users can.
How acceptance criteria drive UAT
UAT only works well when there is an agreed, written standard to test against. That standard is the acceptance criteria: a clear statement, set out in advance, of what each part of the software must do to count as complete.
Acceptance criteria should be agreed early, normally as part of the statement of work, and they should be testable. "The system is easy to use" cannot be tested; "a user can raise an invoice in under two minutes" can. They should cover both functional and non-functional requirements, so behaviour and qualities like speed are both checked.
The UK Government's Service Manual sets out testing as a core part of building digital services well, checking them against clear expectations rather than vague impressions. With criteria written down before UAT starts, the result is a fact, not an argument: each item is met or it is not.
Who on your side should run UAT
UAT should be done by the people who will use the software every day, not by managers signing off from a distance and not by the supplier. The testers need to know the real tasks the system has to support, because they are checking it against the actual job.
Choose a small group that covers each main role the software serves. If a system is used by sales, finance and warehouse staff, all three should be represented, because each will use it differently and notice different problems.
Give them time to do it properly. UAT is real work, so the people doing it need space in their week and a clear timeline written into the project plan. A rushed UAT, squeezed around a full workload, finds far fewer problems than an honest one.
UAT works best when the project was set up for it Good UAT depends on clear acceptance criteria and an honest timeline, both agreed long before testing starts. Red Eagle Tech's bespoke software development service builds testable acceptance criteria into the statement of work from the outset, so your UAT is a fair, straightforward check rather than a guessing game. If you would like to talk a project through, the form below is the place to start.
