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 [CTFL-FA] oder der iSQI Certified Agile Tester [CAT] 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 (siehe Abbildung 1).
Abb. 1: Die Testpyramide
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 [Cri09]. Sie haben es die „vier Testquadranten“ genannt, da sie den Test basierend auf Überlegungen von Brian Marick [Mar03] anhand von zwei Dimensionen in vier signifikante Gruppen eingeteilt haben (siehe Abbildung 2).
Abb. 2: Die vier Quadranten
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 [Kan02]. 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 wie es im Entwicklungsumfeld den Begriff „code smell“ gibt, den Entwickler riechen, wenn sie 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, Acceptance-Test-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: It depends. 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.
Referenzen
[CAT]
iSQI’s Certified Agile Tester®, siehe:
http://www.agile-teaming.org
[Cri09]
L. Crispin, J. Gregory, Agile Testing – A practical Guide for Testers and agile Teams, Pearson Education, 2009
[CTFL-FA]
ISTQB Certified Tester – Foundation Level Extension: Agile Tester Extension Syllabus, siehe: https://www.istqb.org/downloads/syllabi/agile-tester-extension-syllabus.html
[Kan02]
C. Kaner, J. Bach, B. Pettichord, Lessons Learned in Software Testing, John Wiley & Sons, 2002
[Mar03]
B. Marick, Exploration through examples (Blog), 2003, siehe:
http://www.exampler.com/old-blog/2003/08/21/
