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?
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?