User Acceptance testing is not about seeing if the system works according to specification. Instead it is about finding out if the system will deliver a capability your organisation needs to meet its business objectives. A fuller description is given in What is UAT and Why do it.
The formal definition of UAT used by the ISTQB in their "Glossary of Terms used in Software Testing" is:
"Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system."
Let's take this bit by bit:
"Formal Testing" - This means tests need to be prepared and planned in advance and the results recorded. It is about thinking through what you want to test and then creating and running them. It is not about playing with the system and seeing what develops. Inevitably all that happens then is the main path is tested repeatable which in effect means that if it worked once it will work again, and if it failed once it will fail again.
This is not to say that ad-hoc testing should not form part of the plan. Ad-hoc testing is useful when the actual results of a test differ from the expected results. Then it is sometimes worth exploring the area to see if more information can be found about the difference. An example is when an unexpected button or link is displayed. It is then worth pressing them to see what happens. But even this level of ad-hoc testing needs to be formalised by carefully recording what was done and what the results were.
The purpose of it being formal makes the tests repeatable. If they are repeatable then all you are aware of is that something is wrong but you cannot find out where.
"with respect to user needs, requirements, and business processes" - The focus of UAT is seeing if the system being tested works within the larger system called the business or organisation. It is about testing the interface between the business and the system to see if it will deliver what the business needs done. The focus is not about seeing if the system works according to the specification. Instead the acceptance criteria are focussed on it from the users perspective and must answer the question - does this system deliver what I need?
"conducted to determine whether or not a system satisfies the acceptance criteria" - The objective of the testing is see if the system meets pre-defined acceptance criteria. To determine if the system will match the focus for UAT requires setting down formally what is needed to be tested about the system. These are the Acceptance Criteria and crucially are not tests. They just define the type of behaviours that need to be explored in the system. By setting them down in advance you obtain a clear idea of what it is the system needs to do rather than just running some tests without a purpose and saying that it seems good enough.
"and to enable the user, customers or other authorized entity to determine whether or not to accept the system." - The purpose of UAT is ultimately for a business stake holder to make a balanced decision about whether to accept it or not. It has to be the business as they are the people who will have to use the system. The decision is balanced because more is taken into account then just checking if the system has faults. It will have faults but these must be balanced against if the system would be useful for the business. It is perfectly possible for a system which has areas which do not work according to specification to be accepted into service, whereas another system which works perfectly is not accepted as it does not meet the organisations needs.
Thus the definition shows that the UAT is not about just playing with a system, but is a managed exercise in deciding what is wanted from the system for the business, systematically checking the system, and then making a balanced decision.
- What Is UAT, And Why Do It? - why User Acceptance Testing is important.
- Five reasons not to do UAT and how they affect the project plan.