<p>‘Isn't the app finished at some point?’ - As a software developer at typedigital, I am often asked this question by customers. This question is quite justified, because digital product development, such as that of apps, differs significantly from the finalisation of classic projects in terms of the finalisation of projects. For example, a carpenter finishes his work with a functional piece of furniture, a bricklayer with a weatherproof shell and a chef with a dish that he has brought to the guest.</p>
<p>Why do we software developers never manage to finish our projects in the same way that traditional projects are finished?</p>
<p>Instead of breaking down the numerous complex interactions of our code with other software, hardware, external providers, etc., the following statement offers a first attempt at an explanation:</p>
<p>‘WhatsApp is built by Meta, the company behind Instagram and Facebook and even they don't get their software bug-free.’</p>
<p>Writing complex software that is 100% free of errors is almost impossible. So-called ‘bugs’, i.e. errors or malfunctions in the code, occur again and again, which ensure that the programme does not work as expected.</p>
<p>What is possible, however, is to test the code using software tests in such a way that most of these bugs never make it to the user, but are eliminated beforehand. And if you take the right methods to heart right from the start, you will be rewarded with bug-resistant and solid software in the end.</p>
<h2>Test Driven Development</h2>
<p>The term ‘Test Driven Development’ should no longer be unfamiliar to anyone in the world of IT. Basing your code on requirements-based tests reduces costs in the long term, as maintenance costs and the time required to analyse errors are greatly reduced.</p>
<h2>Automated testing</h2>
<p>When we talk about software testing in this article, we are primarily referring to automated tests. This means that the software requirements are incorporated into the code in the form of tests. This testing of newly written code can be used during the development process to detect errors before the programme is made available to users. According to Frühauf et al, such an approach can ‘eliminate 85% of errors’¹ at a low cost. Considering that bug fixing is much more expensive and errors in the software would limit the user experience to such an extent that users could reject the product.</p>
<h2>The building blocks of a good test system</h2>
<p>As an <a href="https://typedigital.de/en/blog/external-software-agency-commission/" target="_blank" rel="noopener">agency for digital products</a>, we work with three different types of tests in our software department: unit tests, integration tests and system tests (end-to-end tests).</p>
<p>Unit tests involve testing individual functions and methods of our programme in isolation in order to check the functionality of the code quickly and easily.</p>
<p>The disadvantage here is that interaction with other functionalities could still ultimately lead to errors. Testing this interaction between modules and services is known as integration testing. We ensure that our components work together correctly and that the desired behaviour occurs when they interact. Writing such tests takes longer, is a little more complex and still does not cover all possible interactions.</p>
<p>In the past, the model of the ‘testing pyramid’ was often used for the quantity of different types of tests, in which the basis was on extensive unit tests, while fewer integration and end-to-end tests took place towards the top. Today, however, people are increasingly talking about the ‘testing cup’. In this model, integration tests take centre stage, while the number of unit tests is reduced and end-to-end tests remain at the top. This shift reflects the modern approach of relying on more comprehensive tests in development, which offer a higher degree of realism. Each of these three test methods still has its area of application and a good interplay of unit, integration and system testing helps us to greatly reduce the susceptibility of our software to errors.</p>
<p><img src="https://typedig.uber.space/assets/6f931982-2ad8-469d-9477-afd480fab0ab?width=1898&height=1017" alt="Testing Methods"></p>
<p><em>A comparison of the modern ‘testing trophy’ vs. the ‘test pyramid’ method</em></p>
<h2>Improving software quality through testing</h2>
<p>Now that it is clear that well-written tests make our software less prone to errors, let's look at what this means for the work of developers. Tests not only help to avoid errors, but also to write better code.</p>
<p>Requirements-based tests ensure that the code that is tested fulfils the predefined requirements. And not only that! If different functionalities are broken down into smaller parts when tests are set up, it is in the nature of things that programmers end up dividing their code into functions, which greatly improves readability and simplifies potential refactorings, i.e. the reworking of software. Through the now test-driven development of our own code and its documentation in tests (tests also serve developers as a kind of documentation of desired behaviour), we ultimately also manage to avoid duplications, simplify continuous work on new features and guarantee high development productivity in the long term.</p>
<h2>Save costs in the long term with the right software tests</h2>
<p>Developing solid software involves costs and many clients are tempted to forego code testing in order to save costs. However, considering that 75 - 80% of the resources used to develop a system are spent on maintenance and enhancements², you should not cut corners in this case.</p>
<p>Much of the work on our software begins after the first release, and to make this work efficient and cost-effective requires initially incurring the additional costs for testing and guaranteeing high development productivity in the long term.</p>
<p>Do you have questions about your current software project? Then get in touch with us! We will be happy to support you with your project.<br><br>_ _ _</p>
<h6>¹ Frühauf, K., Ludewig, J., Sandmayr, H. (1988). Qualitätssicherung. In: Software-Projektmanagement und -Qualitätssicherung. Leitfäden der angewandten Informatik. Vieweg+Teubner Verlag, Wiesbaden. https://doi.org/10.1007/978-3-322-94671-3_5</h6>
<h6>² <strong id="docs-internal-guid-63ae9ff4-7fff-9ec3-f346-f38d2f8f83f1"> Lientz, B., Swanson, E., & Tompkins, G. (1978). Characteristics of application software maintenance. Commun. ACM, 21, 466-471. https://doi.org/10.1145/359511.359522.</strong></h6>