UAT (User Acceptance Testing)
User acceptance testing is the phase in which business users test a system against real processes to confirm it supports the work they need to do. It follows system and integration testing and is run by the business rather than by the delivery team. Its output is a documented acceptance decision, with any remaining defects explicitly accepted.
What it contains
UAT is built from test scenarios written in business language, each with steps, expected results, a tester and a status. Scenarios usually follow end-to-end processes rather than individual screens — take an order through to invoice, onboard a customer, close a period — because the point is to test the process, not the software feature by feature.
Around the scenarios sit five things. Entry criteria, defining what must be true before UAT starts: build deployed, environment stable, test data loaded, prior test phases complete. A defect log with severity and status. Exit criteria, defining what completion means. A daily or weekly progress view showing execution against plan and open defects by severity. And an acceptance record naming who signed and what they accepted. That combination — cases, defects and a dashboard answering how far through and what is still broken — is the shape of the UAT workbook.
How it is used
UAT runs on a fixed window, usually two to six weeks, with daily triage of new defects and a weekly progress report. Two figures drive it: percentage of scenarios executed and passed, and open defects by severity. Together they answer whether the phase will finish on time and whether the product is acceptable.
The phase also feeds the go/no-go decision. UAT completion, or completion with a named list of accepted defects, is a standard readiness criterion in the go-live checklist and on the readiness scorecard. Where UAT runs in parallel with data migration — which it usually does, since testing needs migrated data — the two are managed together, which is why the migration and UAT tracker is one workbook.
Where it goes wrong
UAT is late more often than it is early, and the cause is almost always upstream. System testing overruns, the build lands days before UAT is due to start, and the window is compressed rather than moved because the go-live date has been communicated. Entry criteria exist to make that compression a visible decision rather than a silent one.
The second failure is business testers who were never released from their day job. They are named in the plan, available in theory, and testing in the gaps between operational work. Execution rates then run at a fraction of the plan and the shortfall appears in week three.
The third is testing against synthetic data. Clean, invented records pass. Real data — the historic accounts, the unusual configurations, the records with twenty years of accumulated oddity — is what breaks the system, and if it appears for the first time after go-live it appears as an incident.
The fourth is exit criteria that were never agreed, or were agreed and then quietly relaxed. "No open severity 1 or 2 defects" is a criterion; "most things work" is not. Where defects are being accepted rather than fixed, that acceptance belongs in writing with an owner and a date, alongside the hypercare arrangements that will carry them.
Related terms
System integration testing precedes UAT and is run by the delivery team. Entry criteria define readiness to start; exit criteria define completion. Defect triage is the process of assigning severity and ownership to what UAT finds. Regression testing confirms that fixes have not broken working functionality. Acceptance is the formal business decision that ends the phase.
Questions
Who runs UAT?
Business users who perform the processes in question. The delivery team supports the environment, the data and defect resolution, but does not execute acceptance testing on the business's behalf.
How long should UAT last?
Long enough to execute the scenarios and retest fixes, typically two to six weeks depending on scope. Compressing the window without reducing scenarios simply moves the testing to production.
Can go-live proceed with open defects?
Frequently, provided each remaining defect is recorded, assessed and explicitly accepted with an owner and a workaround. The distinction is between accepted defects and unknown ones.
What data should UAT use?
Migrated production-like data wherever possible. Synthetic data passes tests that real data fails, which defers the failure to live running.