Quality Insurance

How does a change in the software affect your business process?
What's the risk of having an issue in production? What's the occurrence of -  and damage on failure?


Most business fear lies in signing analysis documentation to send it off to development. They suddenly become responsible for knowing what they want and how they want it, before ever trying it out. Making mistakes is human, not being able to see the future is human as well. So why would you sign a document, knowing mistakes are most probably inside?
What else could we do, except for agile product delivery to deliver the clients explicit and implicit changing needs? And even there, how can we prevent a business going broke as a result of a software defect that was not found during development?

For example:
http://www.reuters.com/article/2012/08/02/knightcapital-loss-idUSL2E8J27QE20120802

The answer might be.. QUALITY INSURANCE (or QI)

Why the term QI?

Quality insurance is a term used to oppose the often wrongly used term 'Quality Assurance'

How would that conceptually work?

We would make a difference between soft- and hardware insurance.
By default, this insurance system would not focus on the underlying infrastructure. Neither is it explicitly excluded from the insured scope.

A software insurance policy could be taken after the Go/No-go decision was positive and would start at the end of supplier warranty.
For starters, the business processes in scope of the insurance policy would be described by a team of experienced analysts and testers.
An intake is done on the delivered product in a technical go live in a production-like environment.
This intake would consist of an exploratory test.

Possible product issues and risks are reported. Per identified risk, an insurance fee is mapped to an insured amount.
The interesting risks to insure are the ones with a very low probability of occurrence, but having a very high impact on failure.

The company can then decide to reduce risks (and insurance costs) by fixing defects if the fix cost is lower than the fee or decide to insure themselves for this risk.

   
What would be the Strengths?

• Increase the business attention on product risks. Issues can be resolved before go-live.
• The business can go live with a product they are not sure about resulting an overall decreased project failure.
• Direct linking of risks and issues with costs. This confronting exercise increases awareness.

 What would be the Weaknesses?

• Resolving issues late in the development cycle is still more expensive. The direct cost of software delivery is not reduced but rather increased due to the additional insurance policy.

What would be the Opportunities?

• Level out the current overrated importance of certification  - a tester will need to prove what they're worth. Also development quality will stand more in the picture. 
• The real value of a good tester becomes visible. The tester's function would get more appreciation and direct value. 
• The value of the Exploratory Testing method can be proven. Only by exploring, focusing and de-focusing, the dangerous underlying issues, inconsistencies and process gaps can be found... and insured.
• Increase software quality by increasing the awareness of the cost on failure.

What would be the Threats?

• Decrease of software quality and user satisfaction due to competitive insurance policies. 
• Decrease of insurance quality due to competitive insurance policies