Warum Scrum ohne Testautomatisierung nicht funktioniert (I)

Bild: Flickr/Thisisseba - CC BY-SA 2.0

 "Was bringt das eigentlich?" Diese Frage habe ich mir in den letzten Jahren erstaunlich oft anhören dürfen, wenn es um das Thema Testautomatisierung ging. Selbst im agilen Projektumfeld gibt es immer wieder Projektleiter, Manager und Entwickler denen nicht klar ist warum man diesen Aufwand betreiben soll. Diese Skepsis ist sogar erklärbar, denn wenn man auf die notwendigen Schritte für die Automatisierung eines Tests schaut, dann erscheint die zu leistende Arbeitsmenge auf den ersten Blick unverhältnismäßig hoch zu sein: die Ermittlung von IDs und Xpathes, das Schreiben der Testskripte, die Parametrisierung der Testdaten, das Gruppieren zu Testsuiten, das Starten und Ausführen dieser Suiten, das Auswerten der Ausführungs-Reports, zuletzt das manuelle Nachtesten der fehlgeschlagenen Tests - all das kostet viel Zeit und damit auch viel Geld. Ich kann mich an einen Manager erinnern, der seinen Unwillen in einem symptomatischen Satz zusammenfasste: "In der gleichen Zeit hat der Tester doch die dreifache Zahl von User Stories manuell getestet." Damit hatte er vollkommen Recht. Und zugleich vollbrachte er damit das Kunststück, die drei zentralen Irrtümer des agilen Testens in einem Satz zusammenzufassen. Schauen wir sie uns an:

Erster Irrtum: Tests muss man immer nur einen Sprint lang durchführen
Zugegeben, ein bisschen verleitet Scrum zu dieser Fehlannahme. Die Software wird in diesem Vorgehen bereits in der Anforderungsphase in kleine, für sich selbst funktionsfähige Bausteine, bzw. User Stories zerlegt, die nach und nach erstellt werden und dann sofort lauffähig (und damit auch vollumfänglich getestet) sein müssen. Wenn diese Komponenten aber abschließend getestet und im besten Fall bereits live gegangen sind, entfällt doch der Bedarf weitere Tests durchzuführen - oder? Nun, nicht ganz. Da zukünftige User Stories das bisher erstellte Gesamtsystem laufend erweitern kann nicht ausgeschlossen werden, dass die bereits fertigen Teile beeinträchtigt oder beschädigt werden. Da Scrum aber verlangt, dass die Anwendung nach jedem Sprint Go Live-bereit ist, muss in jedem Sprint ein vollständiger Regressionstest aller Funktionen stattfinden, selbst wenn diese zu einer User Story gehören, die schon längst abgenommen ist.

Zweiter Irrtum: Regressiontest bedeutet, dass man die Akzeptanztests der User Stories wiederholt
Auch da bedarf es eines genaueren Blicks auf die Details. Es ist eben nicht so, dass die Summe aller Akzeptanztests eine gute Testabdeckung der Software ergibt. Akzeptanztests in ihrer ursprünglichen Form machen nur während des Sprints Sinn, in dem die Story umgesetzt wird, zu der sie gehören. Würde man sie danach eins zu eins in die Regression übernehmen, würden Probleme entstehen: Zum Einen wird die in früheren Stories entstandene Funktionalität oft durch spätere Stories verändert. Ältere Akzeptanztests sind dann nicht mehr zutreffend oder sogar obsolet. Zum anderen können verschiedene User Stories Schnittmengen haben, durch die es zu Akzeptanztests kommt, die sich teilweise auch in anderen Stories wiederfinden. Würde man sie trotzdem alle zu Regressiontests machen, entstünden in den Testsuiten Redundanzen und erhöhter Pflegeaufwand. Um diese Effekte zu vermeiden ist es notwendig, die Akzeptanztests abgeschlossener User Stories zu verwerfen und stattdessen eine auf dem aktuellen Entwicklungsstand beruhende, nach jedem Sprint aktualisierte Regressionstestsuite zu erstellen.

Dritter Irrtum: Regressionstests werden nur am Sprintende durchgeführt
Ein weiterer Irrtum, der auf dem alten Wasserfall- bzw. V-Modell beruht, in dem man noch so vorgegangen ist. In Scrum ist dieses Vorgehen hochriskant: Wenn Tests erst am Sprintende durchgeführt werden, können Fehler auch erst ganz zum Schluss entdeckt werden. Zu dem Zeitpunkt fehlt aber die Zeit um sie wieder zu beheben, die Stories können nicht abgenommen werden, der Sprint scheitert. Im schlimmsten Fall stellt sich heraus, dass man Zeit und Geld verschwendet hat, weil man die Arbeit von Beginn an anders hätte machen müssen. Um dem vorzubeugen ist notwendig, dass die Regressionstests regelmässig, am besten sogar nach jedem Checkin von neuem Code durchgeführt werden.

Betrachtet man diese drei Irrtümer (und ihre Widerlegungen), so ist der Sinn der Testautomatisierung sofort klar: Wenn es notwenig ist die Testsuiten praktisch täglich auszuführen, wenn diese Suiten permanent größer werden und wenn sie ausserdem nach jeder User Story-Abnahme aktualisiert und sofort wieder ausgeführt werden müssen, dann ist das schon nach kurzer Zeit manuell nicht mehr zu leisten. Man hat also die Wahl: entweder man verzichtet auf die vollständige Qualitätssicherung der Software (und verstößt damit gegen eine ganze Reihe agiler Prinzipien), oder man automatisiert.