A Collection is a selection of features, articles, comments and opinions on any given theme or topic. It allows you to stay up‑to‑date with what interests you most.
Login here to access your saved articles and followed authors.
We have sent you an email so you can reset your password.
Sorry, we had a problem.
Tags related to this article
Published 9 September 2019
User acceptance testing (UAT) is defined by the International Software Testing Qualifications Board as formal testing with respect to user needs, requirements, and business processes, which is conducted to determine whether or not a system satisfies certain acceptance criteria. It is an essential aspect of many types of technology contracts, but is often overlooked.
On the one hand, those without technical backgrounds may gloss over specification or testing details. On the other, software engineers and other technology specialists may fail to consider the commercial or legal implications of how the contract is worded. This note aims to break down the key aspects of the UAT process, and provides a checklist of things to consider from both a customer and a supplier’s perspective.
WHY CARRY OUT USER ACCEPTANCE TESTING?
UAT enables the customer to determine whether or not to accept the particular software, hardware, infrastructure, or other technology in question. This is particularly important because after formally accepting the supplier’s product, the customer will lose its ability to reject the system and receive a refund, absent a contractual breach or other course of action. The only remedy typically remaining for the customer after acceptance will be damages, which can be both difficult to ascertain and even more difficult to obtain.
Given the variety of things which can go wrong when a new product is deployed or integrated, customers will normally seek to carry out some type of user acceptance testing (UAT) in the final phase of development, before the application or system is moved into the final market or production environment. In plain English, this allows a customer to “try before they buy”. In most cases, the customer may either accept the system as delivered, accept subject to requested modifications, or reject the system entirely.
The idea behind UAT sounds both straightforward and intuitive. However, in practice it can be complicated by a variety of factors. Each of the following must be considered on a case-by-case basis, in light of the relative bargaining power and informational asymmetry between the parties.
To discuss anything covered in this update, or technology contracts more generally, please contact Tim Ryan or your usual DACB contact.
London - Walbrook
+44 (0) 20 7894 6320
+44(0)20 7894 6978
Patrick Hill, Graham Ludlam