Agilität durchzieht den Alltag der Entwicklungsabteilungen. Wo sie noch nicht praktiziert wird, da wird sie gerade eingeführt. Doch wie sieht der Wandel von herkömmlichen zu agilen Entwicklungsansätzen aus? Welche Fallstricke gibt es und wie wird die Qualitätssicherung, insbesondere der Test, dadurch verändert? Welche Konsequenzen ergeben sich für die bekannten Rollen im Test? Es ist offensichtlich, dass die Umstellung auf eine agile Vorgehensweise tief greifende Änderungen mit sich bringt. Auch der Test bleibt davon nicht verschont. Also umarmen wir den Wandel und entdecken die Möglichkeiten für den Test.
Agile wird oft als Projektmanagementmethode beworben. Das ist auch verständlich, denn die Beratungsindustrie lebt davon, Ideen in verkaufbare und greifbare Produkte zu verpacken. So gibt es verschiedenste Varianten von Agile mit unterschiedlichen Namen, die eine Fülle an Werkzeugsets, Methoden und Vorgehen beinhalten. Und wer diese brav umsetzt, der soll den Nutzen erfahren dürfen: Abbau von Bürokratie, Beschleunigung der Entwicklung von effektiv nützlichen Ergebnissen und Maximierung des Kundennutzens.
Unserer Ansicht nach ist Agilität aber viel mehr als das. Es ist eine Kultur und eine Haltung, die ein Team selbstorganisierend, mutig und transparent ihre Ziele verfolgen lässt. Und dadurch stellen sich tief greifende Veränderungen ein: mehr Selbstwirksamkeit der Mitarbeiter, mehr Engagement, größere Zufriedenheit und mehr Flow bei der Umsetzung der Aufgaben.
Veränderungen fallen jedoch nicht vom Himmel und gestalten sich selten rein wie im Lehrbuch beschrieben. Irgendwo muss man einfach mit der konkreten Arbeit beginnen. All die agilen Prinzipien, Methoden, Best Practices, Prozeduren und festgelegten Vorgehen sind ein sehr guter Anfang.
Ein Beginn nach Scrum oder Kanban à la Lehrbuch ist ein erfolgsversprechender Einstieg in die agile Welt. Und auch Ausbildungen zu agilem Testen, wie die Agile Extension zum ISTQB Certified Tester Foundation Level oder der iSQI Certified Agile Tester bringen Sie auf den Weg. Und wenn diese Prozesse einmal laufen, sind damit die ersten Erfolge zu erreichen. Doch nach unserer Erfahrung zündet der Boost für Nutzen und Erfolg erst, wenn die agilen Werte im Team, beziehungsweise der Organisation verinnerlicht und die zugehörigen Prozesse etabliert sind.
Ein Indikator dafür sind die Ergebnisse der Retrospektiven, dann nämlich, wenn das Team beginnt, konstruktiv den gelebten Prozess infrage zu stellen und für die konkrete Situation passend umzugestalten. Es entwickelt sich das eigene, agile Vorgehen, das zum Team und zum Kontext passt und den Einzelnen die Möglichkeit bietet, sich nach ihren Fähigkeiten und Interessen einzubringen und die gemeinsamen Ziele zu erreichen.
Wir wollen hier ein paar Aspekte und Fragen aus dem agilen Testen rauspicken, um Ihnen einen Eindruck davon zu geben, was Sie auf Ihrer Reise erwartet.
Testautomatisierung – die Testpyramide
Eine straffe und effiziente Testautomatisierung ist in agilen Projekten essenziell. Oft wird dafür das Modell der Testpyramide verwendet: Diese beschreibt die Arten der durchzuführenden Tests, ihre Einsatzhäufigkeiten, die damit verbundenen Kosten sowie die Abhängigkeiten zwischen den einzelnen Testarten und -stufen.
Beispielsweise ist es oftmals so, dass automatisierte Unittests die Basis bilden, die entwicklungsbegleitend und vor allen anderen Tests durchgeführt werden. In Abhängigkeit vom Aufbau des Systems sind verschiedene Zwischenstufen möglich, bis hin zu den finalen manuellen Tests im Rahmen der Abnahme durch den Kunden.
Das Big-Picture: die vier Testquadranten
Im selben Atemzug mit der Testpyramide werden auch oft die vier Testquadranten genannt. Diese helfen uns in Projekten oft, die ganzen unterschiedlichen Testarten, ob dynamisch oder statisch, funktional oder nicht-funktional, in einem Bild einzuordnen.
Janet Gregory und Lisa Crispin haben sich einmal grundlegend Gedanken gemacht, welche Tests es in agilen Projekten braucht und wer sie idealerweise macht. Grundsätzlich greifen Testexperten gerne auf das V-Modell zurück, um festzulegen, welche Reviews oder Tests wer wann machen muss und das auch, wenn ihr Projekt gar nicht nach dem V-Modell arbeitet. Das mag noch für manche Kanban-Teams einigermaßen funktionieren, da Kanban hier grundsätzlich offen ist. Aber in den meisten agilen Teams sind die Integrationsstufen sehr eng beieinander und personell kaum voneinander getrennt.
Da Gregory und Crispin beide aus einem XP-Umfeld kommen, haben sie nach einem konsequent anderen Ansatz gesucht und so das bislang wirkungsvollste Modell gefunden, das sich in der Praxis schon vielfach bewährt hat. Sie haben es die “vier Testquadranten” genannt, da sie den Test basierend auf Überlegungen von Brian Marick anhand von zwei Dimensionen in vier signifikante Gruppen eingeteilt haben.
Testverfahren
Die Ideen der klassischen Testverfahren haben natürlich auch im agilen Kontext weiterhin Gültigkeit und sollen Anwendung finden: das Zusammenfassen ähnlichen Verhaltens wie bei den Äquivalenzklassen, das Betrachten von Grenzfällen wie bei der Grenzwertanalyse oder auch der Fokus auf logische und technische Zustände wie beim zustandsbasierten Test. All diese Methoden bieten im Kern auch weiterhin die Möglichkeit, Testfälle nach dem Motto zu erstellen: So wenig wie möglich, so viel wie nötig.
Doch für ein explizites Durcharbeiten dieser Methoden fehlt in agilen Projekten meist die Zeit. Daher ist es gerade hier essenziell, die Ideen dieser Methoden zu verinnerlichen und nicht nur prozedural abzuarbeiten. Natürlich muss dieser Punkt unter Berücksichtigung des Einsatzes in sicherheitskritischen Umgebungen noch einmal hinterfragt werden.
Exploratives Testen
Exploratives Testen ist eine wertvolle Ergänzung zu strukturierten Tests. Im agilen Kontext erhalten diese Tests noch viel mehr Bedeutung. Erfahrene Testexperten wie Cem Kaner und James Bach plädieren für einen kreativen Testansatz, nach dem der Tester von seiner Intuition und nicht von einer Methode oder von einem Werkzeug gesteuert wird. Ein guter, kreativer Tester wird ahnen, wo die Fehler liegen.
Dieser Ansatz läuft auf eine Erforschung der Software hinaus. Der Tester stößt in das System hinein und verfolgt Pfade, die eventuell zu Fehlern führen können. Wenn er keine findet, kehrt er zurück und verfolgt einen anderen Pfad. Aufgrund seiner langjährigen Erfahrung wird der erfahrene Tester wissen, wo er zu suchen hat. Ähnlich des im Entwicklungsumfeld geläufigen Begriffs “code smell”, den Entwickler riechen, wenn sie einen suboptimalen Code sehen, könnte man sagen: Tester nehmen den “bug smell” wahr.
In unseren Projekten haben wir noch eine weitere spannende Beobachtung gemacht. Gute, erfahrene und explorativ arbeitende Tester nutzen die strukturierten Testverfahren implizit – sie haben deren grundlegenden Ideen bereits verinnerlicht.
Und damit geht es bei den Testverfahren erst los. Session-basiertes Testen, AcceptanceTest-Driven Development und Behaviour-Driven Development spielen mit der gemeinsamen Qualitätsverantwortung im Team und helfen, Qualität im ganzen Prozess zu leben.
Und was ist jetzt mit dem Testmanager?
Zu guter Letzt stellt sich die Frage nach den Rollen im Testprozess: Braucht man noch einen Testmanager im agilen Projekt? Die Antwort ist ganz eindeutig: Es kommt drauf an. Es liegt auf der Hand, dass in einem professionellen Projektumfeld – egal ob traditionell oder agil – viele qualitätssichernde Aufgaben organisiert und durchgeführt werden müssen. Während im traditionellen Ansatz ein Testmanager im Fokus der Testplanung und -steuerung steht, soll das agile Team die Qualität selbst organisieren. Aber gerade in agilen Projekten kann es für das Team bereichernd sein, auf jemanden zurückzugreifen, der Test- und Qualitätssicherungs-Know-how hat, der Testverfahren kennt und das Team bei den Testaktivitäten coachen kann.
Häufig gestellte Fragen
Ist Agilität nur eine Projektmanagementmethode?
Nein. Agile wird oft so beworben, weil sich Ideen als Werkzeugsets, Methoden und Vorgehen gut verkaufen lassen. Tragfähiger ist das Verständnis von Agilität als Kultur und Haltung: Ein Team verfolgt selbstorganisiert, mutig und transparent seine Ziele. Daraus entstehen mehr Selbstwirksamkeit der Mitarbeiter, mehr Engagement, größere Zufriedenheit und mehr Flow bei der Umsetzung der Aufgaben.
Woran erkennt man, dass ein Team Agilität wirklich verinnerlicht hat?
Ein Indikator sind die Ergebnisse der Retrospektiven. Das Team stellt den gelebten Prozess konstruktiv infrage und gestaltet ihn für die konkrete Situation um. So entwickelt sich ein eigenes Vorgehen, das zu Team und Kontext passt und den Einzelnen Raum für Fähigkeiten und Interessen gibt. Der eigentliche Nutzen zündet erst, wenn Werte verinnerlicht und Prozesse etabliert sind.
Wozu dient das Modell der Testpyramide in agilen Projekten?
Die Testpyramide ordnet die durchzuführenden Testarten samt Einsatzhäufigkeit, Kosten und Abhängigkeiten zwischen Testarten und Teststufen. Häufig bilden automatisierte Unittests die Basis, sie laufen entwicklungsbegleitend und vor allen anderen Tests. Je nach Systemaufbau folgen verschiedene Zwischenstufen, am Ende stehen die manuellen Tests im Rahmen der Abnahme durch den Kunden.
Warum passt das V-Modell schlecht zur Testplanung in agilen Teams?
In den meisten agilen Teams liegen die Integrationsstufen sehr eng beieinander und sind personell kaum voneinander getrennt. Damit verliert die klare Zuordnung, wer wann welches Review oder welchen Test durchführt, ihre Grundlage. Für manche Kanban-Teams funktioniert es noch einigermaßen, weil Kanban an dieser Stelle offen ist. Testexperten greifen trotzdem oft darauf zurück, auch ohne V-Modell-Projekt.
Was leisten die vier Testquadranten?
Sie teilen den Test anhand von zwei Dimensionen in vier signifikante Gruppen ein und helfen, dynamische und statische sowie funktionale und nicht-funktionale Tests in einem Bild einzuordnen. Janet Gregory und Lisa Crispin entwickelten das Modell aus der Frage, welche Tests agile Projekte brauchen und wer sie idealerweise übernimmt, aufbauend auf Überlegungen von Brian Marick.
Braucht man klassische Testverfahren wie Äquivalenzklassen im agilen Umfeld noch?
Ihre Ideen gelten weiter: ähnliches Verhalten zusammenfassen wie bei Äquivalenzklassen, Grenzfälle betrachten wie bei der Grenzwertanalyse, logische und technische Zustände prüfen wie beim zustandsbasierten Test. Für ein explizites Durcharbeiten fehlt in agilen Projekten meist die Zeit. Deshalb zählt das Verinnerlichen der Ideen statt prozeduraler Abarbeitung. In sicherheitskritischen Umgebungen ist das erneut zu hinterfragen.
Ersetzt exploratives Testen strukturierte Tests?
Nein, es ergänzt sie und gewinnt im agilen Kontext an Bedeutung. Der Tester wird von seiner Intuition gesteuert, nicht von einer Methode oder einem Werkzeug: Er stößt in das System hinein, verfolgt mögliche Fehlerpfade und kehrt um, wenn er nichts findet. Erfahrene explorative Tester nutzen die strukturierten Verfahren dabei implizit, weil sie deren Grundideen verinnerlicht haben.
Wer verantwortet Testplanung und Qualität in einem agilen Team?
Das Team organisiert die Qualität selbst, während im traditionellen Ansatz ein Testmanager im Fokus von Testplanung und Teststeuerung steht. Die qualitätssichernden Aufgaben verschwinden dadurch nicht. Bereichernd ist jemand, der Test- und Qualitätssicherungs-Know-how mitbringt, Testverfahren kennt und das Team bei den Testaktivitäten coacht. Ob dafür eine eigene Rolle nötig ist, hängt vom Projektumfeld ab.
