środa, 14 maja 2014

The Economy of Quality Assurance

The product quality required by customers must of course be correctly defined: do you need, for example, a fast car, a luxury limo or perhaps a cheap car to go shopping? Or is it a lorry, or a very robust off-road to cross Altiplano plateau? Finding the answer should of course be the obligation of market research, or business analysis, or requirements elicitation, or product owner, but – alas – it is often informally delegated to testing (testing as co-dependent behaviour .). This issue has been discussed by many.

I intend to tackle another, but equally if not more important question: how can the required product quality be assured as effectively and as efficiently as possible? In other words, how much quality assurance is just enough, but not too much?

On the fly, this presentation will address a number of test-related issues, very crucial, but normally discussed in a chaotic, haphazard way, such as:
  •     what is the goal of testing
  •     what are the relative benefits of unit/developer testing
  •     is exploratory testing better than non-exploratory testing
  •     should testers be vacuum-cleaners?
There are some slow and costly QA methods: describing and validating requirements very thoroughly in advance, then controlling everything during development many times and verycarefully. Quality control is performed on many levels, even small changes are analysed forever; very extensive regression testing is performed after slightest fixes, to make very, very sure no bug could sneak through. The goal – the required product quality - will be achieved and provable, but… your competitors may have reached the same goal faster, and cheaper! No good.

On the other end of the scale, there are fast and risky methods: coding early without wasting too much time for analysis and design, testing cursorily and keeping your fingers crossed after deployment. Will it work, or will it not? The risk may be too high, especially where failure cost is huge, but there is a lot to win, and risks negligible, if failure consequences are acceptable.

How to find the optimum solution for a given situation, product type and project? The presentation will tackle this issue from four perspectives (see the four images below). For each perspective, I will discuss how various risk levels and risk strategies apply to it.

Perspective 1. What is the optimum level of the relative cost of quality assurance? In other words, how much carefulness is just right?

Perspective 2. What is the optimal share of testing among other quality assurance methods in projects?

Perspective 3. When is it best to test? Boehm’s curve and Ryber’s curve in testing:

Perspective 4. Testing – how much should be thoroughly planned, designed and specified in advance (“scripted”), and how much should you rather test in exploratory style?

Brak komentarzy:

Prześlij komentarz