In any development arrangement between a customer and a software developer for bespoke software, it’s vital that you deal properly with software testing and acceptance.
In the absence of a paid-for support service, most developers offer only a limited warranty period after acceptance so customers should ensure that they are not deemed to have accepted any software release until they have had the opportunity to test it and sign it off. Customers should resist any provision that assumes acceptance just because they’ve allowed a given number of days to go past without reporting any issues.
On the other hand, if you’re a developer, you should ensure your customers cannot unreasonably delay acceptance. If you’ve agreed that acceptance doesn’t happen until they’ve tested and signed off the release, then you should agree a backstop date to ensure they don’t prevaricate.
Make sure the agreement mirrors reality
It can be tempting to include standard testing and acceptance provisions in an agreement without relating them to the actual processes but this helps neither customer nor developer. Both parties should think carefully about how each release will be tested in practice. Who will test it? Will it be tested in a separate UAT (user acceptance testing) environment before being put into production? If so, should migration from UAT to production be enough to imply acceptance of the software? Will the customer sign an acceptance certificate? How will issues be raised and reported?
If there are going to be frequent releases (e.g. through agile development) then a formal testing process may not be practicable and you might agree that the developer can simply assume acceptance unless issues are raised. If so, then it’s vital that the customer commits enough of its own personnel to engage fully with the agile process and test each new release thoroughly and quickly.
Once the customer and developer have agreed how testing and acceptance will work, the parties should ensure that any agreement between them reflects the agreed processes.
What if it all goes wrong
Any testing and acceptance provisions should always deal with the possibility of failure. If the software doesn’t meet the agreed business and/or technical specifications or any agreed performance criteria you’ll normally allow at least one attempt for it to be remedied. But what if the developer cannot address the issues on the second, or even third attempt?
One option is for the customer to accept the software anyway, often with a reasonable adjustment to the price to reflect any shortfall from the agreed specification.
But what if, after several months of trying to address the issues, the shortfall is still so severe that the software just isn’t suitable for the customer’s purposes? The customer should then have a right to a full refund of all fees paid.
The parties will need to negotiate carefully the amount of time that will need to pass before a refund is possible as well as just how deficient the software has to be. In addition, customers may well want to be reimbursed for the costs they will have incurred from the whole wasted exercise as well as any costs of delay and of seeking an alternative supplier.
On the other hand, the developer will want to ensure there is no liability other than a refund of fees – the developer will already be suffering substantially through lost profits and all its costs to date (unless the failure is covered by its insurance).
Matt Worsnop is an Associate Solicitor at BHW Solicitors in Leicester and writes regularly on software law matters. Matt can be contacted on 0116 281 6235 or by email at matt.worsnop@bhwsolicitors.com.