User Acceptance Testing (UAT)

User acceptance testing is the final validation stage in which representatives of the business or the user community confirm that a system meets the requirements it was built to satisfy and is fit for its intended purpose. It is conducted after functional testing, typically in an environment closely resembling production, and its outcome is a decision about whether to release.

It answers a different question from the testing that precedes it. Developer and quality assurance testing establish whether the system behaves as specified; acceptance testing establishes whether what was specified actually meets the business need. Work can pass every functional test and still fail acceptance, because the specification was incomplete, because a process was misunderstood, or because a real-world case nobody documented is not handled.

The most consequential confusion is between acceptance testing and usability testing. Acceptance testing uses people who know the business process, working through scenarios to confirm the system supports them. Usability testing observes representative users encountering the product without guidance, to discover whether it can be understood and used. Substituting one for the other is a serious error: a system can be accepted by knowledgeable stakeholders and remain unusable by the people it was built for.

Participant selection determines what the exercise is capable of finding. Testing conducted by the project team, or by stakeholders who have been involved throughout and know how the system is intended to work, validates that the build matches the shared understanding and finds little else. Including people who will actually operate the system, and who have not been part of the design conversation, surfaces the gaps between intended and actual process.

Scenario design should follow real work rather than feature lists. Walking through the operational tasks the system must support, including the awkward exceptions that constitute much of real practice, finds problems that a feature-by-feature check does not. Realistic data matters equally, since systems that behave correctly with clean test data frequently fail on the malformed, incomplete, and unusual records that production contains.

The stage is structurally vulnerable to compression, because it sits at the end of a schedule that has usually already slipped. Acceptance testing is then conducted in a fraction of the planned time by participants squeezing it around their normal responsibilities, and defects found are triaged into post-launch fixes. Scheduling it with realistic duration, securing participants' time in advance, and agreeing in advance what severity of finding would delay a release are what prevent it becoming a formality.

Defect triage criteria should be agreed before testing begins rather than negotiated under pressure once findings exist. Establishing which categories of problem block release, which are fixed immediately after, and which are recorded for later removes the argument from the moment when the commercial pressure to proceed is greatest and the judgment is least reliable.

Because acceptance confirms fitness for business purpose while saying nothing about whether end users can actually use the system, both forms of validation are needed. In practice the acceptance stage is planned within product development as part of the release process, while the separate question of whether real users can complete their tasks is answered through user research, and for internal systems the operational realism of the scenarios usually depends on involving the IT department and the teams who will support the system after launch.