With contracts for software development and implementation, testing is an area often taken for granted, as the focus is on the front-end and final delivery. Testing is a critical part of the process, but may not get the attention it needs – until things go wrong.
Those involved need to consider what testing objectives should be met and the impact failed tests may have on the project, says Heidi Leslie, a senior associate with legal firm Bell Gully.
Leslie says the following are the critical questions for the business:
• Who is responsible for the testing? There are likely to be different layers of testing, involving both parties to varying degrees, at each step. While “acceptance testing” by the customer is generally contemplated by development contracts, the contract should also address what other testing should occur along the development path.
• What are the testing parameters? The client is likely to have a set of requirements that must be met by the software. Do these requirements yield a specific checklist that can be tested or should separate testing criteria be developed?
• Is the developer obliged to test the software as it is developed to ensure built-in quality? Build in a provision for reporting requirements during the development process, so that problems encountered along the way are not just swept under the carpet.
• What are the key goals of the project? If staying on budget and on time are the key drivers of the project, not all aspects of the software may be tested. However, who will bear the risk of the minimal testing may still be addressed in other ways in the contract.
• What are the exit provisions if the specifications cannot be met? The parties should consider providing for a means of ending the testing cycle; such as a right of termination or a provision allowing the software to be accepted on amended terms.
• Are there any interoperability requirements to be met? Developed software may work perfectly on its own, but defects will emerge when it needs to interoperate with other software or on other systems.
As well as specific testing criteria, the contract should clearly set out what the software is intended to be used for. To address this there should be an express warranty of fitness for purpose.
It is prudent practice to involve a software tester in the development of the testing schedules, particularly for large or critical software development projects.
By addressing these issues at an early stage of the projects – before testing occurs – already complex projects can be less “testing” for all involved, concludes Leslie.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.