A well-known Dutch politician (Willem Drees) once said: “Social Security should be a safety net, not a hammock!” He might have been talking about software testing. Testing, too, should be a safety net, not a hammock.
Many organizations or projects use a variety of test levels. For example, a series of unit test, unit integration test, system test, system integration test, functional acceptance test, user acceptance test, end-to-end test and production acceptance testing is no exception. This may seem sensible, however, it may well create lazy developers. “I deliver my code on time and I don’t have to worry about whether I introduce errors in it or not, because after me the code will be extensively tested anyway.” And, lo and behold, the developer dives into his hammock!
It appears that in organizations or projects that are not accustomed to arranging and executing many test levels, software with fewer errors is delivered. How is this possible? The answer is actually quite simple. Because of the many tests the programmer feels less responsibile for the quality of his product. In situations where software is put into production almost immediately after a unit test, the programmer is forced to take responsibility. After all, when something goes wrong, everyone knows who is to blame. In short, reducing and/or integrating test levels, and at the same time appealing more to the developer’s, or actually, all project members responsibility, promotes the delivery of quality software.
This will make testing a safety net again rather than a hammock!