Direct answer
User acceptance testing (UAT) is your check that the software does what was agreed, done by the people who will use it, against criteria written before the build started. It is not a general impression at the end. If the criteria are written, the scenarios come from real tasks, the right people sign off, and the record is kept, acceptance is a short, calm step. If any of those is missing, it turns into an argument.
This checklist is for custom software and web applications in general. If you are testing an AI agent specifically, see testing an AI agent before launch, which covers the model-specific checks this page does not.
1. Write acceptance criteria before the build
Acceptance criteria are statements that are either true or false when you check them. They belong in the written scope, agreed before work starts, so both sides know what done means.
- Phrase each as a user doing something and a result you can observe: 'A manager can approve a request and the requester sees the new status'
- Cover the main flows, the roles and permissions, and the important failure cases (invalid input, missing data, a user without access)
- Include non-functional expectations that matter to you and can be checked, such as which browsers and devices must work
- Mark what is out of scope so a missing extra is not mistaken for a defect
- Avoid words that cannot be checked: 'fast', 'intuitive', 'robust'. Replace them with something you can observe
2. Build test scenarios from real tasks
Do not test screens; test jobs. Take the actual tasks your team does in a normal week and write each as a start-to-finish scenario: what the person has, what they do, what they should end up with.
Include the awkward cases people really meet: a customer with two accounts, a request that needs correcting, a record edited by two users, a file that is too large. Bugs cluster where real work is untidy. Ask the people who do the job today what usually goes wrong; they will name cases the specification never mentioned.
3. Decide roles and who signs off
Name three roles before testing begins, and keep them separate where you can.
- Testers: people who will really use the software, not only the project sponsor
- Coordinator: one person who collects findings in one place, so feedback is not scattered across email and chat
- Approver: the person with authority to accept on your behalf, named in advance
- Vendor contact: who answers questions and confirms fixes
4. Prepare test data
Testing with three tidy demo records proves little. Agree what data testers will use: realistic volumes, realistic mess and a range of cases. Where real customer or personal data is involved, decide up front whether the test environment may hold it, and confirm what you are allowed to copy. If you are unsure, take advice on your obligations rather than assuming.
Also agree who can reset the test environment, so a tester who breaks something does not block everyone else.
5. Triage defects: blocker or later
Every finding needs a category, agreed before testing starts, or every finding will feel urgent.
- Blocker: a criterion is not met, data could be lost or wrong, or a core task cannot be completed. Must be fixed before go-live
- Should fix: the task can be completed but the experience is clearly wrong. Fix now if cheap, otherwise schedule
- Later: a preference or an idea. Logged for a future release, not a defect
- Out of scope: a new requirement. Handled through the change process described in the written scope, with any effect on price agreed in writing
6. Re-test after fixes
A fix can break something nearby. After each round of fixes, re-run the failed scenarios and then a short set of your most important scenarios again, so you know the fix did not damage what already worked. Keep this set small and stable; it becomes your regression list for every later release.
Ask the vendor to say what changed with each fix, so testers know where to look. If your team has automated checks in place, they can help with repeat runs, but a person who knows the job should still confirm the important flows.
7. Keep a sign-off record
Acceptance should leave a record, not a memory. Keep one document that lists the criteria, the result for each (passed, failed and fixed, or accepted with a known limitation), the date, the version tested, who tested and who approved.
If you accept with known issues, list them by name, with what will happen to each and when. Sign-off should also confirm the handover items due at go-live, such as the code repository, hosting and domain access in your name. If the written scope attaches payment or a milestone to acceptance, keep the record with the contract, and have a lawyer review contract wording where that matters.
8. What happens after go-live
Acceptance is not the end of testing; it is the end of the agreed build. Decide in advance how problems found after launch will be handled: how they are reported, who triages them, what response you can expect and what is treated as a fix versus new work. Watch the first days of real use closely, because real users find things testers did not.
Keep the criteria and scenario list. When you request the next feature, the same checklist applies, and the regression set tells you what must keep working. See web application build timeline for where acceptance sits in the overall schedule, and web application access requirements for the access you will need to provide before testing can begin.
How LATYNEX approaches it
LATYNEX agrees one scope in writing before work starts; whichever vendor you use, ask for acceptance criteria to be part of it before the build begins. If you are planning a build, begin with web application development.
Questions
Who should do user acceptance testing?+
The people who will use the software in their daily work, with one coordinator collecting findings and one named approver. The vendor should fix and explain, not test on your behalf.
How long should UAT take?+
It depends on the size of the build and how prepared your testers are. Agree the testing window and the number of fix-and-retest rounds in the written scope, so it does not become open-ended.
What if we find a problem after we have signed off?+
That depends on what the written scope says about post-launch fixes. Agree this before sign-off: how issues are reported, and which are treated as fixes of agreed behaviour versus new work.
Do we need automated tests as well?+
Automated checks are useful for repeatable regression, but they do not replace acceptance by real users. Ask your vendor how they test before handing over to you, and what you receive.
How is this different from testing an AI agent?+
This page covers acceptance of custom software and web applications generally. AI agents need extra checks on model behaviour, which the separate AI agent testing guide covers.