Try before you buy

We will start optimistically and assume that you are installing new technology in the property. Before you sign on the dotted line do remember the concept of User Acceptance Testing, which is often overlooked.

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. Here we consider 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.

Common complications

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.

Back to basics. Clearly define specifications within the contract itself. Ensuring that the supplier is fully aware of the customer’s requirements from the outset will help to prevent complications from arising during the testing phase.

Pay or delay? Consider condition payment on the successful completion of testing. It is not uncommon for customers want upwards of four to six weeks in order to comprehensively test the product, the supplier will want to limit the amount time available for testing, or otherwise ensure some form of payment before acceptance.

Have an internal strategy in place.  Testing is of no value without an internal strategy detailing how the product will be deemed to have met its business requirements. If other systems will be exposed during testing, it may also be worthwhile to revisit any disaster recovery or business continuity plans.

Failure vs Defect? What constitutes a “failure” will need to be distinguished from a minor “defect”, for example. The supplier must also consider the costs associated with fixes, patches, and other modifications, and whether any additional charges should apply in such instances.

Keep an eye on the clock.  All of the activities should adhere to an agreed timetable, taking into account time and resources required and eventualities if the product fails its testing, or delivery does not materialise on time. Most testing clauses will also include language to the effect that the customer will be deemed to have accepted the product, unless notification is received by the supplier by a certain date.

Maintain open lines of communication. Technology contracts are collaborative endeavours. Development and modification can be the most difficult and nuanced part of an agreement, and can easily lead to disputes between customers and their suppliers if not handled appropriately. By having a dedicated point of contact and open lines of communication throughout the process, you may be able to avoid unnecessary headaches.

Your comments

Read our comments policy here