Testing Value

Image by James Gordon via FlickrI'm unclear as to what my actual interpretation of the value of testing is but I need to get some thoughts out.

Software testing does not have a measurable deliverable in the sense of a tangible product. It basically provides a potential of value. This potential can be accorded to the following:

• An in depth understanding of the system which might not be available within any other development team
• Insuring the expectation of the system's potential
• Identifying additional uses of the system

You don't buy insurance for the return on investment but rather as a means of being able to cover yourself should the insured item become in some manner impaired or absent. It should thus be somewhat reasonable to see the cost of testing as being similar to the purchase of an insurance policy. The value insured, is where the question re-arises. An insured item has a price and it is reasonable to expect some sort of guarantee against the cost. In insurance the guarantee is only as good as the company holding the policy. Would anyone put a guarantee on the state of the software after it has been through the testing cycle?

To come back to the insured value. To obtain an insured value, one could look at the business requirements. A conventional technique is to prioritize the functions. The prioritization process in itself will identify those areas that add the most critical to the business. It is likely that these processes are the ones that add the most value and thus need the most insurance (or testing). Using some weird weighting-to-tester cost to company figures it's intuitively obvious that a dollar value can be generated for the value the testers are there to insure.

From this scheme it can be noted that various supplementary metrics can be applied against the generated dollar amount. These metrics could provide business level feedback of the cost a bug represented had it not been found (using weighting to cost and fudged with severity). Possibly interesting to establish a basic formula for doing this - also if it might even be remotely useful outside of a theoretical obscurity (or just being hilarious).

Information on a system is a long term benefit that could be idealized only by the establishment of a software testing department with effective retention policies. Cross system or domain knowledge can be considered to the be an additional value brought in by test team. This would be a fuzzy value that equates to reduced time to idealization rather than a physical amount. It could also be interpreted as improving the quality of the test effort using past experience. I'm not sure that some scheme could be devised to measure this in terms of a dollar value...

Related articles

• Businesses fear lost revenues after poor software testing [via Zemanta]
• Poor software testing hits companies in the pocket [via Zemanta]
• Stay focussed on fuzzy tests, warn security experts [via Zemanta]