Agile Testing


5 Empfehlungen für die Qualitätssicherung in der agilen Software-Entwicklung

Von Daniel Fiederling, Systems Integration & Quality Assurance

Agile Entwicklungsansätze haben sich in den vergangenen Jahren zunehmend in der Softwareentwicklung durchgesetzt, weil sie vor allem eine hohe Flexibilität gewährleisten.

Dafür gibt es gute Gründe. Der Funktionsumfang einer Anwendung muss nicht bereits zum Start „in Stein gemeißelt“ werden, sondern kann vielmehr im Verlauf der Entwicklung weiter ausdefiniert und bei Bedarf erweitert werden.

Dieses agile Prinzip stellt jedoch insbesondere Tester vor ganz neue Herausforderungen.

Wer im besten Wortsinn agil, also beweglich, bleiben will, der muss bereit sein dafür besondere Regeln aufzustellen – und sich auch an diese halten.

Wir haben aus der gelebten Praxis heraus fünf Empfehlungen, mit denen Sie die Qualitätssicherung in agilen Entwicklungsprojekten meistern.

1. Ein „lebendes“ Testkonzept erstellen

Machen Sie sich vor Beginn des Implementierungsprozesses Gedanken darüber, welche Folgen Fehler in der Software haben können und leiten Sie daraus ab: „was“, „wie“ und „in welchem Umfang“ während der Entwicklung getestet werden muss. Wir empfehlen dazu ein Testkonzept nach IEEE 829-2008 Standard.

Das Testkonzept definiert die „Leitplanken“ für das Vorgehen des Testteams.

Sollte sich dann im Entwicklungsverlauf herausstellen, dass definierte Test-Szenarien und Prozesse auf Grund von Änderungen der Anforderungen angepasst werden müssen, können diese auf Antrag des Entwicklerteams durch den Testverantwortlichen überarbeitet werden.

Regelmäßige Retrospektiven mit allen Projektbeteiligten stellen sicher, dass jederzeit auf Situationen reagiert werden kann, die sich im Verlauf des Testings ergeben. Ziel ist es, über den gesamten Testprozess hinweg Verbesserungen iterativ zu realisieren.

2. Durchgetestete, lauffähige Versionen am Ende jedes Sprints

Aus jedem Sprint resultiert ein lauffähiges Inkrement der Anwendung, welches bereits vollständig qualitätsgesichert ist. Eine hohe Release-Frequenz bedingt es, dass die Anwendung viel häufiger umfangreich getestet werden muss. Die Anwendung jedes Mal manuell zu testen, ist aufwandstechnisch unrentabel.

Es muss sichergestellt werden, dass alle Funktionen – unabhängig davon, ob neu hinzugekommen oder bereits vorhanden – durch automatisierte Tests geprüft und in einen kontinuierlichen Build-Prozess eingebunden werden. Schlagen die automatisierten Tests fehl, können Fehler vom Entwicklungsteam zeitnah und mit „frischem“ Blick auf die betroffene Funktion behoben werden. Automatisierte Tests sind die solide Basis eines agilen Test-Prozesses. Um Fehler zu minimieren, sollten diese unbedingt regelmäßigen Reviews unterzogen werden.

Unabhängig von automatisierten Tests müssen zusätzlich manuelle Tests durchgeführt werden. Um den Testaufwand dafür einzugrenzen, sollten neu entwickelte Funktionen und solche, bei denen häufiger Probleme auftreten, priorisiert werden. Neue Funktionen müssen möglichst schnell nach Fertigstellung getestet werden, also bereits während des Sprints und nicht erst am Ende. Entwickler erhalten somit zeitnahes Feedback zu erkannten Problemen und können diese ebenso zeitnah beheben. Dieses Vorgehen ist wesentlich effizienter, als Fehler erst kurz vor Sprint-Ende und unter hohem Termindruck zu beheben.

Die Vorteile liegen auf der Hand: Der Entwicklungsprozess gerät nicht aufgrund so genannter „Showstopper“ ins Stocken und Release-Zyklen werden eingehalten. Tester können ggf. bis zur Fehlerbehebung andere Features testen oder – entsprechende Erfahrung vorausgesetzt – sogar selbst in den Quellcode einsteigen, debuggen oder unterstützend Ursachenforschung betreiben und dokumentieren.

Der Fehler kann somit wieder deutlich schneller durch die Entwickler behoben werden. Wurde der Fehler behoben, kann der Tester zu seinem ursprünglichen Testfall zurückkehren, den Bugfix validieren und den Test an der zuvor fehlerhaften Position fortsetzen. Mit diesem agilen Testansatz profitieren neben den Entwicklern vor allem auch die Tester von schnellen Problemlösungen.

Wurden die Tests von neuen bzw. besonders fehleranfälligen Funktionen abgeschlossen, können Tests für weniger wichtige Funktionen oder explorative Tests durchgeführt werden. Bei explorativen Tests wird auf Basis der Intuition und Erfahrung der Tester „unstrukturiert“ getestet und auf diesem Weg mögliche Fehler der Anwendung identifiziert.

Das Vorgehen ist unkonventionell, bietet jedoch enormes Potenzial, weil die Tester dazu angeregt werden über den „Tellerrand“ von Anforderungen oder bestehender Testfälle hinaus zu blicken. Das bietet die Möglichkeit, abseits vorgegebener Routen Fehlerzustände zu provozieren.

Ungeachtet dessen, wie intensiv Teilbereiche agil getestet werden, müssen in regelmäßigen Abständen Regressionstests eingeplant werden. Hierbei werden wirklich alle manuellen Tests erneut durchgeführt und die komplette Anwendung ausführlich getestet. Ziel ist es, Fehler aufzudecken, die durch die Weiterentwicklung entstanden sein können. Die Häufigkeit, Art und der Umfang solcher Regressionstests sind, wie alle anderen Testvorgehen auch, im Testkonzept zu definieren.

3. Keine neuen Funktionen in den Release-Zweig einbauen

Die größte Herausforderung beim Testing in agilen Entwicklungsprojekten besteht meist darin, rechtzeitig und umfassend zu Testen und dabei immer wieder angepasste Funktionen, die bis zum Release-Termin neu hinzukommen, zu berücksichtigen.

Die Lösung ist eine Sprintplanung, die eine Fertigstellung neuer Features nicht erst bis zum Sprint-Ende-Tag berücksichtigt, sondern bis zum Erreichen des Zeitpunkts für den „Code-Freeze“. Danach dürfen in den Release-Zweig keine neuen Features mehr hinzukommen.

Ist der Zeitpunkt des „Code-Freeze“ erreicht, müssen Entwickler sich primär auf die Behebung von Bugs konzentrieren, damit diese bis Sprint-Ende behoben und rechtzeitig nachgetestet werden können.

Wurden alle bekannten Bugs gefixt, können Features weiterhin in Feature-Zweigen entwickelt und nach Release bzw. Sprint-Ende mit dem Release-Zweig zusammengeführt werden.

Stellt man fest, dass die Entwicklung aller geplanten Features deutlich vor Sprint-Ende umgesetzt sein wird, kann das Sprint Backlog um zusätzliche Funktionen erweitert werden. Diese können dann ausgeplant und umgesetzt werden, während sich Tester weniger kritischen Aspekten der Anwendung widmen.

Grundsätzlich gilt: Es ist wichtiger die Qualität vorhandener Features zu gewährleisten, als Features oder wichtige Teilbereiche ungetestet zu veröffentlichen. Offene Features können schnellstmöglich nachgereicht werden, aber dafür in ebenso hoher Qualität.

4. Bei veränderten Anforderungen Tests anpassen

Einer der größten Stärken des agilen Entwicklungsansatzes ist es, dass nicht alle Funktionen bereits zu Beginn der Entwicklung detailliert ausdefiniert sein müssen und Feedback schnell eingearbeitet werden kann. Daraus resultiert gleichzeitig die größte Herausforderung für die Qualitätssicherung.

Durch das Ändern einer Anforderung – und sei sie noch so klein – müssen unter Umständen viele Tests mindestens angepasst, oft jedoch gründlich überarbeitet werden.

Hier hilft es; in beide Richtungen Querverweise zwischen den Tests und den Anforderungen herzustellen. Veränderte Anforderungen müssen in jedem Fall sauber dokumentiert werden.

Sollte für die Änderung einer Anforderung ein neues Ticket im Anforderungs-managementsystem erstellt werden, so muss auch die Verlinkung zur ursprünglichen Anforderung hergestellt werden.

Alle mündlichen Absprachen müssen ebenfalls protokolliert und mit der Anforderung verknüpft werden. Durch die Schaffung eines „Single Point Of Truth“ und die Referenzierung zwischen Anforderungen und Tests können alle Beteiligten schnell auf die relevanten Informationen zugreifen.

Für die Tester bedeutet das, dass bei Anforderungsänderungen schnell die relevanten Tests gefunden werden und bedarfsgerecht angepasst werden können. Doch auch umgekehrt: Wenn ein Test fehlschlägt; kann der Tester schnell quer-prüfen, ob der Testfall noch korrekt ist oder sich Anforderungen inzwischen geändert haben und der Testfall überarbeitet werden muss.

5. Einen „Test-Driven-Development“-Ansatz verfolgen

Wenn Sie den agilen Test-Ansatz auf die Spitze treiben, können Sie den „Test-Driven-Development“-Ansatz wählen. Dabei werden von Testern auf Basis der Anforderungen bereits Tests geschrieben, während Entwickler die zugehörige Funktion noch entwickeln.

Die Tester arbeiten dabei zunächst mit sogenannten „Mocks“ (Platzhaltern) oder nur grob skizzierten Testfällen, die nach der Fertigstellung der eigentlichen Funktion durch echte Funktionsaufrufe oder detailliertere Tests ersetzt werden.

Das Entwicklerteam profitiert dann bei der Programmierung durch die vorbereiteten Tests, weil es das vom Testteam erwartete Verhalten bereits kennt und somit schon während der Entwicklung die tatsächlichen Ergebnisse quer-prüfen kann.

Das Entwicklerteam muss nicht mehr so viel Zeit in die Entwicklung eigener Tests investieren, sondern kann auf die vorbereiteten Tests des Testteams aufbauen oder diese ergänzen.

Von der Theorie in die Praxis


Natürlich lässt sich nicht alles, was über Methoden und Vorgehen in der agilen Software-Entwicklung geschrieben wird, auf jedes beliebige Projekt anwenden.

Aus eigener Erfahrung wissen wir jedoch, dass es hilft, sich bereits früh mit den Möglichkeiten der unterschiedlichen Methoden auseinanderzusetzen.

Unsere Experten verfügen über Erfahrung in der Konzeption und im organisieren umfangreicher Test-Szenarien. Gerne teilen wir unser Wissen mit Ihnen und stehen auch einem Austausch immer offen gegenüber.

Wenn Sie Interesse haben, kontaktieren Sie uns. Wir freuen uns auf spannende Gespräche.