User Acceptance Testing UAT

The buyer's own check of a new system before signing it off, done on the real machines with a handful of ordinary working days.

Also known as UAT acceptance testing sign-off testing

Definition

User acceptance testing is the buyer's own test of a new system before they sign it off. Not the builder's test. Yours. You sit down with the software and check that it does the job you paid for.

The best way to do it is to write out a handful of ordinary working days and walk through them. A customer buys three items and pays half in cash and half by card. A patient books an appointment, then calls to move it. A parent asks for a fee receipt from last term. Each one of those is a scenario. Write them before you see the software, so the list comes from your business and not from the screens somebody has already built.

Run them on the real equipment. The phones your staff actually carry, the receipt printer behind the counter, the card machine, the old laptop in the back office. A test on a developer's fast machine proves very little. When Linkysoft hands over a clinic system, we ask the receptionist to run a normal Tuesday morning on her own desk with her own printer. Half of what goes wrong in the first week is a printer, a slow connection or a screen smaller than anyone expected.

Decide in advance who signs. One named person on your side, usually the one who will be blamed if it goes wrong. Put real time in the diary for them, a half day, not twenty minutes between meetings. Then agree what happens to problems found after signing. That is the part people skip. Ask for a written warranty period, thirty or ninety days, in which anything that does not match the agreed scenarios is fixed at no charge.

The mistake we see most is testing only the easy path. Everything works when the customer pays in full and nothing comes back. Test the refund, the cancelled booking, the wrong price, the member of staff who left last month. Linkysoft writes the scenario list with the client before a web application project starts, and uses the same list again for the phone side when it builds the mobile app. It settles the argument about what finished means early, instead of at the end where it costs money.

Questions about User Acceptance Testing

Who should do the user acceptance testing?
The people who will use the system every day, not the technical team. A receptionist, a cashier, a teacher. One named manager signs at the end.
Is it the same as the testing the developers already did?
No. Developers check that the code works the way they built it. This checks that the system does the job your business actually needs, described in your own words.
What happens if we find a problem after we have signed?
That is what a warranty period is for. Agree it in writing before you sign, usually thirty to ninety days, in which anything that does not match the agreed scenarios is repaired at no extra cost.
Do we have to test the phone app separately?
Yes. Screens are smaller, connections drop and the camera and alerts behave differently. Run the same working-day scenarios on the phones your staff really carry.

Still not sure how this applies to your project?

Tell us what you are building and we will answer in plain language.