Wie Agile Testing verändert

Gleich vorweg: Software-Entwicklung ist komplex und Ereignisse können oft erst rückblickend verstanden werden. Auch wenn ich die Transformation zu Agile Testing hier linear beschreibe, soll das nicht heißen, dass sie immer so ablaufen würde. Jeder Kontext ist anders. Erfahrungsgemäß rechne ich aber mit den beschriebenen Auswirkungen:

• risikobasierter Ansatz,
• automatisiertes Whitebox-Testing,
• Fokussierung des gesamten Teams auf Testbarkeit.

Der Punkt von agiler Software-Entwicklung ist die iterativ-inkrementelle Vorgehensweise. Jedes entwickelte Inkrement ist wirklich fertig und potentiell auslieferbar. Das heißt, alle notwendigen Arbeiten für einen Release sind abgeschlossen. Und das schließt auch alle notwendigen Testaktivitäten ein.

Agile Testing unterscheidet sich also von klassischer QA grundsätzlich dadurch, dass es nicht nachgelagert erfolgt, sondern zusammen mit der Programmierung. Das bedeutet, dass alle Testaktivitäten innerhalb eines Sprints abgeschlossen werden sollen. In Kanban unterliegen Testaktivitäten einem WIP-Limit, der Effekt ist aber vergleichbar.

Klassisch gedacht müsste ein neues Feature natürlich erst programmiert sein, bevor es getestet werden könnte. Für den eigentlichen Test verbliebe damit nur ein knapper Zeitraum am Ende des Sprints. Das treibt das grundsätzliche Problem, dass die Zeit für Testing immer zu knapp ist, auf scheinbar absurde Weise auf die Spitze. Wie soll das denn bitte klappen?

Auf Risiko gehen

Eine erste Veränderung hin zu einer agilen Teststrategie ist die Erkenntnis, dass unter begrenzten Ressourcen nur ein risikobasierter Testansatz verfolgt werden kann. Risikobasiertes Testen ist genausowenig neu wie Zeitknappheit beim Testen. Im agilen Kontext rückt es aber in den Vordergrund. Testaktivitäten werden dabei nach Risiko priorisiert, also nach Wahrscheinlichkeit des Auftreten eines Defekts und der Größe des dadurch verursachten Schadens. So können wir in der zur Verfügung stehenden Zeit das Gesamtrisiko bestmöglich reduzieren.

Risikobasiertes Testen konzentriert sich auf zwei Bereiche: zum einen die im letzten Inkrement vorgenommenen Änderungen, zum anderen die dadurch verursachten Regressionen. Da Tester und Programmierer jetzt im Team arbeiten, sind uns Änderungen im Detail bekannt und wir können sie fokussiert testen. Gefundene Regressionen werden unmittelbar im gleichen Sprint behoben. So entfällt das über mehrere Sprints stattfindende Ping-Pong-Spiel zwischen Entwicklung und QA.

Doch es wird besser. In dieser engen Zusammenarbeit von Testern und Programmierern ergibt sich die Chance, Synergieeffekte zu nutzen, um Testaufwände zu reduzieren. Je weniger aufwändig die Tests sind, desto mehr Risiko lässt sich in der gleichen Zeit abdecken. Der Schlüssel liegt darin, Programmierer in die Testaufgaben mit einzubinden.

Willkommen in der Whitebox

Programmierer sind Spezialisten für Automatisierung. Ihr Job besteht schließlich darin, Software zu schreiben. Software, die ihre Benutzer unterstützen soll, indem sie einen davor manuellen Teilprozess automatisch ausführt. Programmierer haben auch naturgemäß ein Verständnis für die Struktur dieser Software. Das ermöglicht einen strukturbasierten Testansatz. Willkommen in der Whitebox!

Strukturbasierte Testtechniken wie Unit- oder Komponententests sind Programmierern in der Regel vertraut. Sie benutzen sie, um bei der Entwicklung Feedback für die Funktionalität von Teillösungen zu bekommen und Denkfehler beim Entwurf schneller zu erkennen. Wird funktionales Testen auch klassisch nachgelagert durchgeführt, ist es wahrscheinlich, dass Tests in Entwicklung und QA dupliziert werden. Diese Duplikation tritt in agilen Entwicklungsteams nur selten auf. Tester können sich überzeugen, dass ein Unit-Test bereits die Funktionalität sicherstellt, die sie ansonsten manuell testen würden.

Viel entscheidender ist aber, dass diese Tests automatisiert sind. Automatisierte Tests können innerhalb von Minuten abdecken, was manuell einen mehrtägigen Aufwand bedeuten würde. In der Regel ist es nicht einmal notwendig, automatisierte Tests selektiv auszuführen. Sie können spätestens bei jedem CI-Build vollständig durchlaufen. Eine hohe Abdeckung bietet also einen ausgezeichneten Regressionsschutz.

Gleichzeitig kommt mit jeder Änderung oder Neuentwicklung die Chance, die automatisierte Testabdeckung für die betroffenen Komponenten zu erhöhen. Der zwangsläufig risikobasierte Testansatz ergänzt sich also perfekt mit den Techniken für automatisiertes Whitebox-Testing. Wenn das Team hier konsequent ist, werden die aktiv entwickelten Teile des Systems innerhalb kurzer Zeit mit Tests abgedeckt sein.

Damit ist eigentlich klar, dass Tester in einem agilen Team darauf abzielen wollen, diese möglichst hohe Abdeckung durch automatisierte Whitebox-Tests zu erreichen. Das heißt nicht zwangsläufig, dass Tester selbst automatisieren. Es ist aber wichtig, Programmierer in die Erstellung der Tests einzubeziehen. Tatsächlich ist es kontraproduktiv, einfach nur manuelle Tests aus der QA zu übernehmen und zu automatisieren. Bei diesen Blackbox-Tests bleibt das strukturbasierte Wissen der Programmierer ungenutzt.

Das bedeutet auch, sich als Tester mit der Struktur der Software auseinanderzusetzen. Wie ist die Software in Komponenten zerlegt? Welche Teilprobleme lösen diese Komponenten? Ist es unmittelbar klar, dass die Kombination dieser Komponenten eine vollständige Lösung darstellt? Gut strukturierte Software erlaubt in der Regel eine Verteilung von Tests in Form der Testautomatisierungs-Pyramide von Mike Cohn.

Super-Power Testbarkeit

Tester und Programmierer wachsen zunehmend zu einem Entwicklungsteam zusammen und gewinnen Vertrauen in die Testautomatisierung. Ihnen wird klar, dass sie alle auf eine möglichst einfach zu testende Software-Struktur angewiesen sind. Das ganze Team hat also jetzt einen Anreiz, die Software möglichst von vornherein testbar zu gestalten.

Ein testbarer Entwurf trennt die risikobehafteten Komponenten (dort wo es wahrscheinlich ist, dass subtile Fehler richtig Schaden verursachen) von anderen, potentiell schwer zu testenden Teilen. Ganz allgemein bedeutet das eine Trennung von fachlichen und technologischen Aspekten, die zum Beispiel in der hexagonalen Architektur auf die Spitze getrieben wird.

Gibt es Legacy-Komponenten, die nicht aktiv entwickelt werden und deren Testabdeckung nicht ausreicht, wird das Team auf eine möglichst starke Entkopplung hinarbeiten, die die Wahrscheinlichkeit von Regressionen und damit den manuellen Testaufwand reduziert. Auch das ist eine durch Test-Feedback bewirkte Verbesserung der Struktur.

Um hohe Testbarkeit zu erreichen ist es wichtig, dass das Team die Möglichkeit hat, auch architekturelle Änderungen vorzunehmen oder anzustoßen. Es ist wichtig, die durch Erfolge in der Testautomatisierung gewonnene Zeit nicht nur in die Neuentwicklung von Features zu investieren. Sie sollte zumindest anteilig für Redesign und Refakturierung freigehalten werden. Ist das Team von der Expertise oder den Entscheidungen eines externen Software-Architekten abhängig, kann das zu einer Bremse werden. Seniorität und Empowerment des Entwicklungsteams sind hier oft der Schlüssel zum Erfolg.

Die geänderte Einstellung des Teams wird auch in Refinement-Meetings deutlich, wo ein integrierter Blick auf die Anforderungen jetzt verstärkt die Frage nach der Testbarkeit aufbringt. Sind die Akzeptanzkriterien testbar? Ist klar, wie sie getestet werden? Lässt sich die Story in der bestehenden Software-Struktur umsetzen? Ergibt sich eine Chance, die Struktur anzupassen, um sie testbarer zu gestalten?

Insgesamt ist ein agiles Team, das seine Teststrategie beherrscht, immer weniger auf aufwändige Ende-zu-Ende-Tests oder manuelle Regressionstests angewiesen. Es verbleibt immer mehr Zeit für kreative Aufgaben. Dazu gehören zunächst Verbesserung der Abdeckung mit automatisierten Tests und Verbesserung der Testbarkeit. Auch im Idealbild verbleiben im Umfang begrenzte manuell-explorative Testaktivitäten. Sie stellen ebenfalls eine kreative Aufgabe dar, die nach dem aktuellen Stand der Technik nicht automatisiert werden kann.

Sofern sich keine Dysfunktion entwickelt oder das Team durch externe Abhängigkeiten ausgebremst wird, wird nach und nach mehr Zeit für qualitativ nachhaltige Entwicklung frei. Tests werden nicht mehr als Bremse wahrgenommen, sondern als Sicherheitsnetz, das es dem Team erlaubt, sich schnell und sicher zu bewegen. Das Team wird zunehmend effektiver.

Tester als Teil eines agilen Entwicklungsteams können die Transformation zu Agile Testing entscheidend mitgestalten. Ihre Aufgaben verschieben sich dabei erheblich – weg von der nachgelagerten Ausführung manueller Testpläne, und hin zu ihren kreativen Aufgaben wie der Identifikation von Risiken, der Gestaltung und Vermittlung der agilen Teststrategie, der Kommunikation mit Stakeholdern und der engen Zusammenarbeit mit Programmierern in einem hoch produktiven Team.