The views of what encompasses software User Acceptance Testing (UAT) within various business units and roles differs greatly. UAT tends to get ‘bogged down’ in debates about scope and purpose if a common shared understanding between all stakeholders doesn’t exist. If managed correctly, the UAT process is usually extremely beneficial for all stakeholders.
The aim of this article is not to be detailed and prescriptive in nature but rather created a broad and common high-level understanding of the topic for all roles involved in software distribution and development. The article is brief in order to encourage wide readership.
What is User Acceptance Testing?
User acceptance testing (UAT) is about the user of the Configuration Item (i.e. software or hardware) testing whether the Configuration Item (CI) addresses the business requirements as documented to be met by the CI. Per the SDLC figure below, UAT (part of Acceptance Testing) tests against the Business Requirements.
UAT is also a significant indication as to whether the CI transition from one team to another is ready to occur e.g. from a vendor or project to a support team, and is therefore performed after all other testing has occurred.
What UAT is Not
UAT is not about communicating new wants and needs nor about testing against new expectations and requirements. All requirements of the CI should be documented and agreed during the Business Requirements stage. It is important that testers and other stakeholders are aware that UAT is testing against the documented business requirements.
The UAT Process
UAT is a formal and defined process as illustrated in the figure of the example acceptance testing process below.
Of specific importance is that, should certain test results differ from the expected result, the means of determining the priority and actions to occur for deviations should be defined in the test strategy or test plan. In other words, a deviation from expectation for any test does not necessarily mean that the test is a ‘failure’ or that it doesn’t meet the business objectives.
UAT is time-consuming however the benefits of UAT significantly outweigh the ‘costs’. Benefits of UAT include:
- Improved defining of business requirements (through knowledge that requirements will be tested).
- Improved solution quality (as developers, configurers etc.) are aware that users will test.
- Improved communication with users as developers, configurers etc. need to meet requirements.
- No ‘last minute’ requirements as UAT is performed against business requirements.
- Users experience the solution prior to ‘go-live’
- Handover into support of the solution is formalised and defined
Glossary of UAT Terms
Below are a few terms related to UAT and their explanations:
Test Cases: A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.
Test Plan: This is a detailed plan of how the UAT will be performed. This document is more detailed than the Test Strategy and more specific to the UAT for the CI to be tested.
Test Script: A document specifying a sequence of actions for the execution of a test. A test script will usually contain numerous Test Cases.
Test Strategy: The test strategy is usually a document detailing all testing to be performed on the CI (e.g. Unit Testing, System Testing, Integration Testing, UAT etc.) and how and who will perform the testing.
See http://www.astqb.org/educational-resources/glossary.php, http://www.istqb.org/downloads/glossary-1.0.pdf and http://msdn.microsoft.com/en-us/library/aa292484%28VS.71%29.aspx for further glossaries.