Bei der Entwicklung, Anpassung oder Installation einer neuen Softwarelösung testen viele Teams erst spät. Dadurch bleiben Fehler, die während der Entwicklung entstehen, lange unentdeckt – was die Korrektur erheblich teurer macht. Kurz gesagt: Je früher ein Fehler erkannt wird, desto günstiger lässt er sich beheben.

In den letzten zehn Jahren hat sich die agile Softwareentwicklung in zahlreichen Unternehmen und Branchen gegenüber den schwerfälligen klassischen Entwicklungsprozessen durchgesetzt. Dieser Artikel zeigt, welche Vorteile agile Methoden bieten.

Zu den klassischen linearen Entwicklungsmodellen zählt das Wasserfallmodell. Hier unterteilen Projektteams die Softwareentwicklung in aufeinanderfolgende Phasen. Erst wenn eine Phase abgeschlossen ist, beginnt die nächste.

Abbildung 1: Wasserfallmodell

Diese klassischen Methoden gelten mittlerweile als schwerfällig und kostenintensiv. Oft bemerken Teams Fehler erst nach der Programmierung, was eine zeitnahe Korrektur erschwert. Agile Methoden wie Scrum setzen genau hier an und schaffen Abhilfe.

Abbildung 2: Agile Softwareentwicklung

Agile Vorgehensweisen strukturieren den Entwicklungsprozess anders. Der Product Owner sammelt die Anforderungen und erstellt daraus einen Product Backlog. Gemeinsam mit dem Scrum Master legt das Scrum Team anschließend fest, welche Anforderungen im nächsten Sprint umgesetzt werden. Diese Aufgaben landen dann im Sprint Backlog.

Abbildung 3: Agiles Testen in agilen Projekten, Peter Moser, https://petermoser.de/agiles-testen-in-der-praxis

Bereits in der Sprintplanung definieren die Beteiligten die Akzeptanzkriterien. Sie legen fest, wie sich die Anforderungen prüfen lassen. Diese Kriterien bilden die Basis für die Testfälle, die von Sprint zu Sprint ergänzt und weiterentwickelt werden. Eine Test-Charta fasst Testziele und -ideen zusammen.

Sobald der Sprint beginnt, bereiten die Teams die relevanten Tests vor. Sie richten die Testumgebung ein, stellen Testdaten bereit und führen die Tests aus – parallel zur Entwicklung der neuen Features. In den täglichen Scrums bespricht das Team etwaige Testblocker oder -hindernisse. Entdeckte Fehler dokumentieren und bearbeiten die Entwickler sofort.

Die Entwickler schreiben Unit-Tests, bevor sie überhaupt mit der Implementierung der Komponenten beginnen – ganz im Sinne der testgetriebenen Entwicklung (Test-Driven Development), einem Kernprinzip von Extreme Programming. Dieser Ansatz sorgt dafür, dass kein ungetesteter Code entsteht. Gleichzeitig vermeiden die Entwickler durch frühzeitiges Refactoring unnötigen Code und konzentrieren sich auf das Wesentliche. Nur wenn alle lokalen Unit-Tests erfolgreich laufen, checken sie den Code ein. Erst dann fließt der Code in einen Build ein.

Mehrmals täglich integrieren die Entwickler den gesamten Code in einem sogenannten „Daily Build“, der automatisch über die Continuous Delivery Pipeline getestet wird.

Eine Continuous Delivery Pipeline umfasst Continuous Integration, Delivery und Deployment – häufig auch als CI/CD-Pipeline bezeichnet. Diese Pipeline gehört zu einer umfassenden Toolkette, die automatisiertes Testen und Versionsverwaltung ermöglicht. Die Pipeline bewegt den Anwendungscode vom Entwickler bis zum Nutzer. Die automatisierten Tests bilden das Rückgrat dieser modernen Delivery-Prozesse.

Nach den erfolgreichen Unit-Tests checken die Entwickler den neuen oder geänderten Code ein. Anschließend startet eine Reihe automatisierter Tests. Diese Tests prüfen die Integration, das Systemverhalten sowie funktionale und nicht-funktionale Anforderungen – etwa Performance, Schnittstellen, Sicherheitsaspekte oder externe Abhängigkeiten. Auf diese Weise verhindert das Team, dass instabiler oder unsicherer Code veröffentlicht wird.

Erst wenn alle Tests erfolgreich abgeschlossen sind, startet der automatisierte Build-Prozess. Da besonders nicht-funktionale Tests eine lange Laufzeit haben, planen Teams sie nicht bei jedem Daily Build ein. Stattdessen führen sie diese Tests gezielt aus – etwa wöchentlich oder vor einem Release. Dasselbe gilt für Systemintegrationstests, die vor allem dann erforderlich sind, wenn neue Schnittstellen angebunden werden.

Im Sprint vor einem Release führen die Teams Systemtests auf einer produktionsnahen Umgebung durch. Der Fachbereich übernimmt bei Bedarf den Abnahmetest. Sobald diese Tests erfolgreich sind, übergibt das Team das Produkt zur Freigabe an DevOps oder ITIL. Zentrale Einheiten unterstützen teamübergreifend mit Services für Testumgebungen, Testdaten, Tools oder Schnittstellenanbindungen.

Auch bei der Testautomatisierung gibt es deutliche Unterschiede zwischen klassischen und agilen Projekten. Klassische Modelle wie das Wasserfall- oder V-Modell sehen meist erst zum Projektende eine ausführliche Testphase vor. Agile Projekte hingegen durchlaufen nach jedem Sprint eine Test- und Qualitätskontrolle.

Im Gegensatz zu sequenziellen Vorgehensweisen setzen agile Projekte automatisierte Tests von Beginn an voraus. Während mit jedem Sprint neue Softwarefunktionen entstehen, wächst auch die Anzahl der Tests. Um eine hohe Testabdeckung sicherzustellen, bauen Teams frühzeitig ein Framework für die Testautomatisierung auf – einschließlich einer funktionierenden CI/CD-Pipeline. Auch wenn zu Projektbeginn noch wenige Tests nötig sind und sich diese auf Komponenten- und Modultests beschränken, sorgt ein gut konzipiertes Framework für einen stabilen Ausbau der Teststrategie.

Spätestens beim Systemtest zeigt sich, dass ein agiles Projekt ohne Testautomatisierung nicht funktioniert. In jedem Sprint testen die Teams nicht nur neue Funktionen, sondern überprüfen auch bestehende Funktionalitäten im Rahmen von Regressionstests. Ein manuell durchgeführter Systemtest nach jedem Sprint würde den Zeit- und Kostenrahmen deutlich sprengen.

Mit jeder neuen Funktion steigt die Komplexität der Software – und ebenso der Testaufwand. Automatisierte Tests und eine zuverlässige CI/CD-Pipeline helfen dabei, diesen Aufwand zu bewältigen. Für manuelle Tests fehlt es den Mitarbeitenden in der Regel an Zeit. Ohne Testautomatisierung könnten am Ende eines Projekts plötzlich schwerwiegende Fehler auftreten.

Deshalb ist es in agilen Projekten entscheidend, von Beginn an ein strukturiertes, automatisiertes Testframework zu etablieren, das mit der Software mitwächst. Und nicht vergessen: Je früher das Team testet, desto schneller lassen sich Fehler beheben – und desto niedriger bleiben die Gesamtkosten der Entwicklung.