Software: a short guide to make testing less testing

Heidi Leslie, Senior Associate | Monday 21 May 2007

In software development projects, the issue of testing can sometimes be overlooked.

In sorting a contract for software development and implementation, it is an area that is often taken for granted with the focus being on the front end and the final delivery. Testing is clearly a critical part of the process but may not get the attention it needs - until things go wrong.

Given the testing provisions of development contracts can be key tools to managing the overall project risk, it is a good idea for business to consider testing objectives upfront - as part of the contract negotiation. Those involved should consider what testing objectives should be met and the impact that failed tests may have on the project. 

Among the questions for parties to ask are:

• 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? This is important so as to avoid attempts to fix bugs at the end of the process. It can be addressed by providing 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? Clients should recognise that if staying on budget and on time are the key drivers of the project, it may be that not all aspects of the software can 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?  Many contracts provide for an endless loop of testing where the test criteria 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 that allows the software to be accepted on amended terms.
• Are there any interoperability requirements to be met?  In many circumstances, developed software may work perfectly on its own, but defects will emerge when it is transferred to the operating environment where it needs to interoperate with other software or on other systems.  Any specific systems or software with which the software will need to operate should be specified and testing should be required to ensure the interoperability requirements are met.

As well as specific testing criteria, the contract should clearly set out what the software is intended to be used for. In many cases, the software may not be fit to go live even if all of the specified tests have been completed successfully. The reverse can also be true. 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 the early stages of the projects - before any testing even occurs - already complex projects can be less "testing" for all involved.