February 10, 2022
Why you need Acceptance Testing in your contracts
Acceptance Testing has historically been seen as something that leads to unnecessarily time-consuming negotiations between suppliers and customers.
However, Law 365 believes that contract negotiations can (and should) be a brilliant opportunity to lay the foundations for a successful future relationship. Acceptance Testing is a great way to do this, and fortunately it’s now becoming a widely recognised, accepted (and even encouraged) process.
Contents
How can agreeing Acceptance Testing protect me?
6 Acceptance Testing essentials
What is Acceptance Testing?
Acceptance Testing gives your customer the opportunity to test your Professional Services deliverables, such as a piece of bespoke software or an app, before they are put into a live environment. While at first glance, this process may seem to favour your customer, it’s actually really important as a supplier to get this right, for many reasons.
How can agreeing Acceptance Testing protect me?
At Law 365, when we receive a contract from the other side, we often see no mention of Acceptance Testing at all! We know it’s always exciting to sign up a new customer as quickly as possible, but this is one area where you really shouldn’t cut corners – failure to agree some basic Acceptance Testing principles can lead to costly delays and even disputes further down the line. For example, you may find you’re in a position where your customer is dragging their feet, or they may have decided that their original requirements have changed or (in the worst case scenario) the customer simply wants to delay milestone payments, all despite you working hard and incurring costs to deliver a fantastic service. So here are six basics of Acceptance Testing which will help to avoid this situation and will protect your business:
6 Acceptance Testing essentials
It’s impossible to have a ‘one size fits all’ approach as it will depend on your business and the deliverables along with various other factors. So, what exactly are we looking for in a robust (but fair!) Acceptance Testing provision in your contract?
1. Define what is being measured in the testing
It’s important to specify which (if any) of your deliverables are going to be subject to Acceptance Testing. The cleanest way to do this is to identify those deliverables that are in scope of Acceptance Testing within your Statement of Work (or other similar document).
2. Agree Acceptance Criteria
Take the time to agree with your customer what your acceptance criteria is going to be. What exactly do you and your customer need to achieve from the deliverable in order for it to pass testing? We would ordinarily expect this sort of detail to be set out in a statement of work. Having a well-defined Acceptance Criteria is critical to define the scope of the project. Without it, your customer could try to reject deliverables simply because they’ve changed their mind, or they could move the goalposts from what was initially agreed. Having a clear, objective criteria agreed upfront mitigates (if not removes) this risk for you as a supplier.
Top tip: Failure to pass Acceptance Testing often leads to delays in payment, so be as specific as possible!
3. Agree how long Acceptance Testing will take
Make sure you agree a specific time period for your customer to complete the testing – we suggest 5 business days as a reasonable starting point, but this will vary depending on the volume and complexity of the testing. If you need to retain some flexibility, you can agree the time period to apply to each deliverable in your Statement of Work.
4. Pass / Fail or “deemed acceptable”
Your customer should be obliged to inform you by the end of the agreed acceptance period whether the relevant deliverable has passed testing or not. But what happens if you hear nothing – is the deliverable accepted? Can you invoice your customer for work completed? To protect you against unnecessary confusion or dispute, we always include a ‘deemed acceptance’ provision in contracts. This means that, if you haven’t been told that a deliverable has failed testing at the end of the acceptance period (or the customer starts using the deliverable in a live environment), the deliverable will be deemed to have been accepted, and you can move on to invoicing your customer and continuing with your other Professional Services work.
5. Rectification
What happens if your deliverable doesn’t pass the agreed acceptance criteria? This isn’t necessarily a disaster, and it does happen – all the more reason to anticipate it in your contract! The way this rectification happens, and how long it takes, will really depend on the deliverable, internal processes, and your reliance on third parties.
If rectification is entirely within your control and you are confident you’ll have the resources readily available to address the issue quickly, we have seen rectification timeframes as short as 5 business days agreed by suppliers.
Where you rely on a third-party vendor, it’s wise to make this period longer (30 or even 45 days is not uncommon). Once rectification has taken place, we’d usually expect the parties to follow the above process again until the relevant deliverable has passed Acceptance Testing.
Top tip: You should only accept an obligation to perform rectification works if the failure to pass Acceptance Testing was directly caused by your actions (or failure to act!).
6. How to avoid a never ending cycle
You may be wondering what happens, from a contractual perspective, if you get stuck in the above loop (Failure of Acceptance Testing - Attempted rectification - Further failure of Acceptance Testing)? Of course, we hope this never happens, but it’s important to cover off every eventuality in your contracts to avoid you being exposed.
So how can we protect you from this? Ultimately, if your deliverable doesn’t meet the acceptance criteria, your customer may consider whether it has rights to bring a contractual claim against you, or even terminate for material breach of the contract (all depending on the specific wording of your contract, of course…). The answer is to address this head on (however unlikely this outcome may be).
A typical approach is to allow you to terminate work on the relevant deliverable where you can show that you are unable to rectify the fault due to an error, defect or fault which is outside of your control. This is important as your customer will expect you to do as much as is reasonably possible to fix a fault which is within your control. We typically see this along with an agreement that the customer will not be charged for work on the relevant deliverable.
Another approach (and one that is potentially less damaging to your ongoing relationship with the customer) is to include a mechanism that allows for the customer to accept the deliverable (even if it doesn’t fully satisfy the acceptance criteria), but the relevant charges will be amended to reflect the reduced functionality. How this mechanism works will depend on the deliverable and how it is intended to be used by the customer in a live environment.
Despite all the best arguments for an acceptance testing process similar to the above, your customer may say “we’ll just agree acceptance on a case-by-case basis in a statement of work” (we hear this argument a lot). This works in principle, but we always recommend having some generic Acceptance Testing wording in your framework agreement or main contract as a fallback position. Of course, it may be that very specific Acceptance Testing provisions apply to a particularly complex/bespoke deliverable, in which case the statement of work is a good place to include specifics.
The moral of the story? If you overlook Acceptance Testing in the rush to get a deal agreed, you’re exposed.
Further reading
- 5 top tips for drafting a Statement of Work (law365.co)
- Statement of Work (SoW) | Law 365 Contract and Policies
- For useful information about all the contracts and policies you need, visit Law 365 solutions | Easy Outsourcing Legal Services