When developing, adapting or installing a new software solution, many teams only test at a late stage. As a result, errors that arise during development remain undetected for a long time – which makes the correction considerably more expensive. In short: the earlier an error is detected, the cheaper it is to rectify.

In the last ten years, agile software development has prevailed in numerous companies and industries over the cumbersome traditional development processes. This article shows the advantages of agile methods.

One of the classic linear development models is the waterfall model. Here, project teams divide software development into successive phases. The next phase only begins once one phase has been completed.

Figure 1: Waterfall model

These traditional methods are now considered cumbersome and cost-intensive. Teams often only notice errors after programming, which makes it difficult to correct them promptly. This is precisely where agile methods such as Scrum come in and provide a remedy.

Figure 2: Agile software development

Agile approaches structure the development process differently. The product owner collects the requirements and uses them to create a product backlog. Together with the scrum master, the scrum team then determines which requirements will be implemented in the next sprint. These tasks then end up in the sprint backlog.

Figure 3: Agile testing in agile projects, Peter Moser, https://petermoser.de/agiles-testen-in-der-praxis

Those involved define the acceptance criteria as early as the sprint planning stage. They determine how the requirements can be tested. These criteria form the basis for the test cases, which are supplemented and further developed from sprint to sprint. A test charter summarizes test objectives and ideas.

As soon as the sprint begins, the teams prepare the relevant tests. They set up the test environment, provide test data and carry out the tests – in parallel with the development of the new features. In the daily scrums, the team discusses any test blockers or obstacles. The developers document and process any errors discovered immediately.

The developers write unit tests before they even start implementing the components – in line with test-driven development, a core principle of extreme programming. This approach ensures that no untested code is created. At the same time, developers avoid unnecessary code through early refactoring and concentrate on the essentials. They only check in the code once all local unit tests have run successfully. Only then does the code flow into a build.

Several times a day, the developers integrate the entire code in a so-called “daily build”, which is automatically tested via the continuous delivery pipeline.

A continuous delivery pipeline comprises continuous integration, delivery and deployment – often also referred to as a CI/CD pipeline. This pipeline is part of a comprehensive tool chain that enables automated testing and version management. The pipeline moves the application code from the developer to the user. The automated tests form the backbone of these modern delivery processes.

After the successful unit tests, the developers check in the new or modified code. A series of automated quality checks then starts. These tests check the integration, system behavior as well as functional and non-functional requirements – such as performance, interfaces, security aspects or external dependencies. In this way, the team prevents unstable or insecure code from being published.

The automated build process only starts once all tests have been successfully completed. As non-functional tests in particular have a long runtime, teams do not schedule them for every daily build. Instead, they carry out these tests in a targeted manner – for example, weekly or before a release. The same applies to system integration tests, which are particularly necessary when new interfaces are connected.

In the sprint before a release, the teams carry out system tests in an environment close to production. The specialist department takes over the acceptance test if required. As soon as these tests are successful, the team hands over the product to DevOps or ITIL for release. Central units provide cross-team support with services for test environments, test data, tools or interface connections.

There are also clear differences between classic and agile projects when it comes to test automation. Traditional models such as the waterfall or V-model usually only provide for a detailed test phase at the end of the project. Agile projects, on the other hand, run through a test and quality control phase after each sprint.

In contrast to sequential approaches, agile projects require automated tests right from the start. As new software functions are created with each sprint, the number of tests also grows. To ensure a high level of test coverage, teams set up a framework for test automation at an early stage – including a functioning CI/CD pipeline. Even if few tests are required at the start of the project and these are limited to component and module tests, a well-designed framework ensures a stable expansion of the test strategy.

The system test is the latest example of how an agile project cannot function without test automation. In each sprint, the teams not only test new functions, but also check existing functionalities as part of regression tests. A system test carried out manually after each sprint would significantly exceed the time and cost framework.

The complexity of the software increases with every new function – as does the testing effort. Automated tests and a reliable CI/CD pipeline help to manage this effort. Employees generally do not have the time for manual testing. Without test automation, serious errors could suddenly occur at the end of a project.

This is why it is crucial in agile projects to establish a structured, automated test framework right from the start that grows with the software. And don’t forget: The earlier the team tests, the faster errors can be rectified – and the lower the overall development costs remain.