What is user acceptance testing, and how does an owner do it before accepting software as finished?
User acceptance testing is the final round of testing, done by the people who will use the software, to confirm it does the job you agreed before you accept it as finished. An owner can run it with a short script of plain-words tasks and real examples, a ranked list of what failed, a re-test of the fixes and a written sign-off that says exactly what was accepted.
What it is, and what it is not
Developers usually test their own work as they build it. User acceptance testing asks a different question: does this do my work, the way my people do it? It happens at the end, before you call the project finished. An agreement may tie final payment to it, so check yours.
It is not the stage-by-stage checking described in the related answer on checking a developer's work before paying for more. It is the last pass over the whole thing, with the people who will live with it.
Who tests, and with what
The testers should be the people who will use the software day to day, not only the person who ordered it. Someone who has never seen it can be useful, because they often click where a real new user would.
Give them a short script. Each line is one task in plain words with the result you expect, such as "book a visit for next Tuesday and check the confirmation arrives". Build it from the checks you agreed earlier, then add a handful of real examples from recent work, with private customer details removed. Ask for a test copy and test data, so that a test does not email a real customer or change real records.
Write down every fault as it appears: what the tester did, what happened, what should have happened, and a screenshot if possible.
Rank what failed
| Must fix before sign-off | Can wait | |
|---|---|---|
| What it looks like | Blocks real work, loses or changes data wrongly, gets money or dates wrong, or exposes private information | Looks untidy, is slower than you would like, or has a clumsy wording |
| What happens | Fixed and re-tested before you accept | Listed with an agreed date, and not a reason to refuse sign-off |
Re-test, then sign off in writing
When fixes come back, re-run the failed lines and then the whole script, because a fix can break something that worked. Sort the fault list with the developer, using the table above, and agree the sort in writing. A new wish that appears during testing is not a failure. It is usually a change to the agreement, so record it separately.
Sign-off should be a short written note with the date, what was tested, who tested it, what you accept, and the can-wait items with their agreed dates. Before you sign, read what your agreement says acceptance triggers, such as a payment or the start or end of a period for fixing faults. A lawyer can read those terms before you sign.
After sign-off
Ideally before the project starts, agree how faults found soon after launch are handled and for how long, and who you tell. Then take the hand-over: accounts in your name, access to the code, notes on how it runs and how to restore it. The related answer on what it takes to keep custom software running covers the upkeep, and the related answer on who owns software built for your business covers ownership.
Related answers
- How do you check a developer's work before paying for more?
- What does it take to keep custom software running after launch?
- Who owns software that was built for your business?
Custom software and apps
Off-the-shelf tools get you most of the way. When the last stretch is where the time goes, we build the part that fits: the dashboard, the portal, the internal tool or the app.