Barry Boehm, an American scientist in the field of software engineering, stated almost 40 years ago that the repair of software errors becomes exponentially more expensive the later these "defects" are identified. Even now, proof of this statement is regularly provided in various IT projects.
Your new bathroom
Imagine that you are going to completely renovate your present, outdated bathroom. First, you weigh, fit and measure everything carefully and then, together with the bathroom supplier, you choose the layout, the shower and the bath, the washbasin and the tiles. The supplier will lay down as much as possible in detail in a design. Because the layout is completely different from your current bathroom, all pipes have to be moved and hidden in the walls. Then the bathroom is placed and the walls are tiled according to the design. When the taps are placed, you turn on the bath and see a thin stream of water coming from the tap. And to your horror, on the wall above the bathtub, there is an ever-growing wet spot...
In the above example, it does not take an American scientist to show that repairing the leak in the diverted water pipe would have been cheaper if tests for leaks had been carried out earlier. Just as it is good to test earlier whether the sockets are in the right place, looking at the design. At an early stage, the possible repair costs for correcting errors are limited.
Simple measures
In terms of complexity, a bathroom can obviously not be compared to an extensive IT project. Nevertheless, simple measures can prevent large (repair) costs, both during the described renovation and in an IT project.
In the graph above, Boehm's theory is compared to the phasing of an IT project. This shows that the costs of making an error during use of the software are many times higher than correcting incorrect requirements.
In the example of the bathroom, the moment of "error detection" lies just before the actual use. Similarly, in an IT project, the focus is often on the user acceptance test. A good measure to counter this is to shift the focus of testing to the system integration test. By using a risk based test approach in this test phase(see also a previous article on this subject), software faults with the greatest damage are made visible first and there is the most time left to solve them. These are usually also the errors with high repair costs if they are only discovered at a later stage.
Another measure lies in the early involvement of testers. If the testers are already involved in the project when the requirements are being drawn up, it is possible to have the first designs tested for testability. Think, for example, about unambiguity or preventing confusion. These 'errors' can then be corrected even before the supplier starts development. An additional advantage is that the testers can already extract many logical test cases from discussions about the design during the first phase. This saves time in drawing up the scenarios to be tested.
Advice
The advice is therefore to organise the testing strategy in such a way that the largest errors are found (and solved) at an early stage. Involving testers in the first phase helps enormously. So you can face 'the new bathroom' with peace of mind...
