Im vergangenen Jahr hatte ich eine Diskussion mit einer Testexpertin über Agile Softwareentwicklung, Software Testen und Scrum. Wir waren beide auf der gleichen Testkonferenz, die primär auf eher traditionelles Tester ausgelegt war. Trotzdem war hier ein dominantes Thema Scrum, Agile Softwareentwicklung und wie testen denn mit diesem Agilen Kram überhaupt funktionieren kann.
In unserer Diskussion kam es schnell zu dem Punkt, bei dem es darum ging, was die Unterschiede zwischen Agil und Wasserfall sind. Besagte Testexpertin war der Meinung, dass Agil nichts anderes als ein Mini-Wasserfall sei. Am Anfang der Iteration werden Anforderungen aufgenommen, diese werden dann umgesetzt, und später am Ende der Iteration getestet. Damit lassen sich dann auch direkt alle bisherigen Methoden nicht nur vermitteln sondern direkt anwenden. Super. Problem gelöst. So geht also Agiles Testen.
Leider stimmt das nicht so ganz. Das Vorgehen löst in meinen Augen vor allem das Problem der traditionell eingestellten Trainer, die auf einmal auf den Agilen Wagen aufspringen sollen, aber birgt gerade im Zusammenspiel mit Agiler Entwicklung auch einige schmerzhafte Probleme. Welche das sind, und was man dagegen machen kann, will ich hier kurz aufzeigen.
Agile Mini-Wasserfälle
Was sind eigentlich Agile Mini-Wasserfälle? Nach ein wenig Forschen zum Thema Waterfall stoße ich schnell auf ein Paper von Winston Royce aus dem Jahr 1970 mit dem Titel Managing the Development of Large Software Systems. Mein persönlicher Favorit aus dem Paper ist das voll entwickelte Modell auf Seite 11, Bild Nr. 10. Hier ein Screenshot.
Was ist das fragen Sie? Nun, das ist das Wasserfall-Modell nach Winston Royce, wenn man das Paper zu Ende liest, und nicht bei der ersten Grafik, die man noch versteht aufhört. Tatsächlich ist es so, dass Royce in dem Paper 1970 erklärt, warum das beschriebene Modell nie funktionieren kann. Was nach der Veröffentlichung geschah, war, dass etliche Manager die Grafik auf Seite 2 im PDF so verständlich fanden, dass sie diese umgesetzt haben, ohne das Paper zu Ende zu lesen, geschweige denn zu verstehen. Royce verbrachte den Rest seines Lebens damit, diesen Fehler wieder richtig stellen zu wollen.
Was sind die Probleme mit der Wasserfallentwicklung nach Royce? Nun, wenn in einer späten Phase der Entwicklung ein Problem festgestellt wird, das dazu führt, dass der gesamte Zyklus noch einmal durchlaufen werden muss, dann kann ich faktisch noch mal von vorne anfangen. Ein Faktum, auf das Leeds und Weinberg bereits 1961 in Computer Programming Fundamentals hinweisen. Wenn ein Problem in einer späteren Phase festgestellt wird, dann muss alles von Beginn an in Frage gestellt werden.
Und wie verbinde ich das mit Agiler Entwicklung? Ganz einfach, in Agiler Entwicklung arbeiten wir mit kurzen Iterationen von einer bis vier Wochen. In dieser Zeit nehme ich Anforderungen auf, designe meine Ideen, erstelle Code, teste ihn und liefere ihn dann aus. Wenn ein Problem auftritt, dann muss ich die Iteration halt noch einmal machen, und von vorne anfangen. Alles kein Problem, oder?
Nicht so wirklich. Was fehlt ist die Erkenntnis, dass es bei Agiler Softwareentwicklung um mehr geht. Wenn ich einen Agilen Wasserfall permanent durchziehe, dann kann es sein, dass sich ein Team tatsächlich lange mit einem schwierigen Thema aufhält. Das führt mittelfristig dann leider dazu, dass ich auch gleich eine Iteration Anforderungen machen kann, gefolgt von einer Iteration Design, gefolgt von einer Iteration Code, gefolgt von einer Iteration Test. Und wenn die Tester in der vierten Iteration mit Testen beschäftigt sind, kann ich ja gleich auch die nächste Iteration mit coden beginnen. Pipelining funktioniert schließlich auch bei Prozessoren wunderbar.
Eine schöne Milchmädchenrechnung. Das ganze würde funktionieren, wenn kein Fehler unterläuft. Beim Pipelining in Prozessoren tritt dies beispielsweise auf, wenn ein Jump-Befehl ausgeführt wird. In dem Fall wird ebenfalls die gesamte Pipeline vollständig geleert, und der Prozessor tut für ein paar Zyklen nichts, die sich die Befehlspipeline erst wieder füllen muss.
Hinzu kommt der Faktor Mensch. So gerne wir auch perfekt wie Maschinen wären, wir sind es nicht. Uns unterlaufen Fehler bei sich wiederholenden Tätigkeiten. Deswegen sind wir in der Lage, aus unseren Fehlern zu lernen, damit wir es beim nächsten Mal besser machen können. Das bedeutet aber leider, dass sich in unsere tägliche Arbeit Fehler einschleichen müssen. Wäre auch schade, wenn ich nichts mehr lernen könnte.
Beim Punkt Lernen sind wir tatsächlich bei einer Lösungsidee für dieses Dilemma. Das zwölfte Prinzip des Agilen Manifests besagt, dass das Team regelmäßig über deren Arbeit reflektiert und sich so kontinuierlich verbessert. Über die Retrospektiven lassen sich in regelmäßigen Abständen konkrete Verbesserungen für eine bestimmte Zeit angehen, und diese vermeintlichen Verbesserungen auch wieder einstellen, wenn sie nichts bewirken. Allein die Einführung von Retrospektiven kann so dazu führen, dass vorherige Mini-Wasserfälle abgebaut werden. In der Tat kenne ich eine ganze Reihe an Teams, die ausgehend von einem Mini-Wasserfall mit Retrospektiven begonnen haben, nur um später genau diese Wasserfälle gänzlich aufzugeben. Ein Zufall? Wurden sie beeinflusst? Vielleicht, vielleicht auch nicht. Fakt bleibt aber, dass keins der Teams wieder zurück zum Mini-Wasserfall wollte.
Weitere Mechanismen für Agile Teams sind die 3 Cs von User Stories: Card, Conversation und Confirmation. User Stories gehören auf eine Karte. Diese Karte umfasst nicht die gesamten Anforderungen, das ist aber auch gut so. In Gesprächen soll ein gemeinsames Bild der Story entstehen. Dieses wird in Form von Akzeptanzkriterien, die vielleicht auch noch automatisiert getestet werden können, festgehalten. Diesen Prozess kann man in einem Mini-Wasserfall auch erhalten, allerdings haben etliche Teams mehr Erfolg damit, ausgehend von den Akzeptanzkriterien, eine Diskussion zu beginnen, die dann letzten Endes auf der Karte landet. Gojko Adzic nennt das ganze Specification by Example, in diesen Breitengraden vielleicht besser bekannt als Akzeptanztest-getriebene Entwicklung (ATDD).
Darüber hinaus wäre es Verschwendung eine Iteration vollständig wegzuwerfen. Aus diesem Grund haben sich in Agilen Teams emergentes Design und emergente Architekturen durchgesetzt. Doch wie sieht es mit emergenten Tests aus? Leider Fehlanzeige bei den meisten Teams. Doch es geht auch anders. Automatisierte Unittests sollten genauso emergentem Design und Architektur entsprechen wie der Produktionscode. Das gleiche gilt für jegliche automatisierten Tests. Leider vergessen zu viele Teams, dass Testautomatisierung Softwareentwicklung ist, und tun sich mit schlechten automatisierten Tests mehr weh, als dass sie ihnen nutzen.
Mit einem Sicherheitsnetz aus automatisierten Tests kann ich darüber den Umfang meiner manuellen Tests zurückfahren. Moment, zurückfahren? Ich dachte, ich kann mit Testautomatisierung alle meine manuellen Tests sein lassen. Nicht ganz. Es gibt immer Fälle, die sich nur mit hohem Aufwand automatisieren lassen oder – einmal autoamtisiert – instabil sind, und mehr Pflegeaufwand bedeuten, als dass sie Nutzen bringen. Ein Beispiel sind Tests für die korrekte Tabulatorreihenfolge in einer Eingabemaske oder die korrekte Platzierung von Elementen in einer UI. Fehler erkennt hier das menschliche Auge sehr schnell. Das Ganze zu automatisierung lohnt sich wegen des Aufwandes nichts, oder der Nutzen ist einfach zu gering, und wiegt in keinem Fall die Kosten auf.
Genau für diesen Fall lohnt sich ein risiko-basierter Testansatz. Dieser zielt bewußt darauf, das zu testen, was potentiell betroffen ist. Kombinieren läßt sich das Ganze wunderbar mit Session-basiertem Testmanagement. Nach jeweils einer Session kann ich das Feedback nehmen, um eine neue Session zu planen. Wenn ich mehr an Testtiefe interessiert bin, plane ich eine Session ein, die mir genau das liefert. Wenn ich das Gefühl habe, es befindet sich kein weiterer Fehler in der Applikation, dann möchte ich aber vielleicht auch eher in die Breite gehen, und gucken, welche Funktionen ich noch gar nicht getestet habe. Oder mich interessieren gezielt die Fehlerbehebungen der letzten Zeit. All dem zugrunde liegt die Erkenntnis, dass ich niemals alles testen kann. Deswegen beschränke ich mich beim risiko-basiertem Testen bewußt darauf, was derzeit für mich interessant ist. Als Mensch kann ich das bewerten, als Maschine – nicht so sehr.
Agile Softwareentwicklung ist also kein Mini-Wasserfall, sondern besitzt seine eigene Dynamik, um genau die Problem mit Wasserfallentwicklung los zu werden. Auch wenn ich auf Punkte wie Teambasierte Softwareentwicklung und übergreifende Kommunikation nicht hier eingegangen bin, spielen all diese Faktoren eine wesentliche Rolle bei Agiler Softwareentwicklung. Wer diese Punkte übersieht, sollte sich vielleicht noch einmal das Paper von Herrn Royce zu Gemüte führen – aber diesmal bitte bis zur Seite 11 lesen.
Ein Gedanke zu „„Agil ist doch auch nur Wasserfall““