Testing makes a major contribution to the development and quality of a product. Nowadays, this statement is uncontroversial, regardless of in which area and according to which model development takes place.

However, integrating independent testing into the development process at an early stage is still difficult for many companies, especially at the integration level. The following statements are heard again and again:

• We test constantly and our developers test alongside.
• We would like to test, but the components XYZ are just not ready yet.
• High time to deal with these "arguments" in detail.

High time to deal with these "arguments" in detail.

Developers should test for themselves - that's right and important. However, a developer often lacks the necessary distance to his code. He is, so to speak, “operationally blind”. For example, if a requirement was unclear, an outdated specification was present, or something was not properly understood, the test would not be able to detect this if performed by the same developer. While the developer can test if his code does what he expects it to do, his expectations may be incomplete or incorrect.

If developers test each other's code, this effect is mitigated, but this additional effort made by the personnel minimizes the development budget, which is usually tight anyway. Apart from that, it is questionable whether the second developer is in possession of a more recent requirements document. In addition, developers usually only have the specification for their components - they often have no access to the other specifications. The result is that at integration level at the latest, they can no longer test.

Meanwhile, the fact that the late execution of tests in the development process does not bring any financial savings has been the subject of many investigations  (e.g. ingenieur.de and xbsoftware.com). In fact, quite the opposite is true. Those who invest early in testing can save a lot of money in the long run. As a general rule, the earlier a fault is discovered in the system, the cheaper it is to rectify it. The bug that never ends up in the code is understandably the cheapest. Avoidable errors result from incomplete, inconsistent or ambiguous requirements. A brief comparison here reveals the great savings potential

On the one hand, we have one or two reviewers who work through the requirements, highlight ambiguities and problems, and create a revised version together with the author of the document. This is sent to the developers.

On the other hand, we have a tester who finds an error, reports it and discusses it with his test manager. The bug is reported to developer 1, who determines that the problem is not related to his component at all. He passes it on to developer 2, who is responsible for another component. Developer 2 doesn't find the bug at first until, after consulting Developer 1, he comes up with the idea that both components have been implemented correctly according to the specification, but the specification doesn't match.

The specification is then revised, at least one of the two components is changed (with the associated component tests) and then returned to the tester for retesting. The regression risk has not yet been considered, nor has the mood of the development team dropped. Of course, not all errors can be avoided and not all problems are identified in the review. However, due to low costs, reviews offer a high potential for cost savings and improvement of the working environment.

If a bug has found its way into the code, it is of course advisable to find it as soon as possible. A developer can change his code faster if he is still deeply involved in the current development process. Part of being human is that we remember what we did yesterday or the day before better than what we developed two months ago. In addition, the regression risk is generally lower because there is less code associated with the bug found, simply because there is less code overall. As in the case of avoidable errors, employee blocking can be avoided by early error detection.

It happens again and again in projects: the integration test only begins late because the development of a component is behind schedule, whether the software is not yet ready for use or a circuit board is not yet available.

In this case, it is worth considering whether the component, or more precisely its interface, can be simulated at system level. If an executable system can be created in this way, at least the interfaces between the other components can be considered. If even data or messages of this component can be simulated (writing messages to a BUS system, injecting entries into a database etc.), the interface to the missing component can also be tested, at least one-sidedly, on the side of the already existing components. If five of six components are ready for use, 5/6 of the integration test can ideally be carried out - as a so-called pre-integration test.

Investing early in error detection t is extremely, both through reviews and independent testing in the early development phase. The advantages speak for themselves: It doesn’t cost much, can contribute to complete error avoidance, enables more efficient error correction, reduces the regression risk and drastically reduces the risk of a development standstill due to blocker issues.

In addition, there’s another advantage: ask the tester or the test manager of an early initiated test about the current project status. He will be able to give you information about all components in a neutral form and without you having to laboriously gather the information from the subproject managers.

If you have further questions about testing, testing management and (pre)integration testing, don’t hesitate to contact us. We look forward to hearing from you.