Wenn ich im Rahmen meiner Coachings die Konzepte der Testgetriebenen Entwicklung (TDD) vorstelle, stoße ich in vielen Unternehmen auf Skepsis: Steht der Nutzen in einem guten Verhältnis zum Einführungsaufwand? Die Benefits von TDD, wie Evolvierbarkeit und Wartbarkeit des Codes, wirken meist sehr abstrakt und sind darüber hinaus auch nur schwer quantifizierbar. Um den Effekt Testgetriebener Entwicklung dennoch greifbar zu machen, kann ein Blick auf eine typische Situation aus dem Entwicklungsalltag helfen.
Donnerstagnachmittag: Der Product Owner trifft sich wie gewöhnlich mit dem Entwicklungsteam zum Backlog Refinement, um neue User Stories zu erörtern und Aufwände schätzen zu lassen. Den Anfang macht eine vermeintlich einfache, überschaubare Anforderung. Nach kurzer Zeit schon haben die Entwickler ein gutes Verständnis, was fachlich gewollt ist, und auch die Akzeptanzkriterien sind schnell gefunden. Beim abschließenden Scrum Poker kommt dann jedoch die Überraschung. Die Entwickler schätzen den Umsetzungsaufwand mit 13 Story Points enorm hoch ein. Der Product Owner ist überrascht und hakt nach. Wie kommt das Team zu diesem Urteil?
Hier wird es nun interessant zu hören, wie die Entwickler ihre Aussage begründen. Drei alternative Antworten, bei denen ihr hellhörig werden solltet, möchte ich im Folgenden etwas näher betrachten.
Variante 1: "Hierfür muss Komponente XY erweitert werden und nur der Ex-Kollege Z und der liebe Gott allein wissen, wie die genau funktioniert."
Es gibt sie in fast jedem System; die berüchtigten Codestellen, welche die Entwickler nur mit größtem Sträuben anfassen. Die genaue Funktionsweise ist unbekannt und man weiß auch nicht so recht, wie man nach der Änderung prüfen soll, ob alles noch so funktioniert wie zuvor. Hinzukommt, dass man für eine saubere Implementierung eigentlich den Code umstrukturieren müsste, doch ohne das Sicherheitsnetz automatisierter Tests wäre das mehr als mutig. Also erfolgt die Änderung an der risikoärmsten Stelle, meist mit der Folge, dass diese Komponente nachher noch schwerer zu verstehen ist.
Variante 2: "Es muss zwar nur eine Zeile im Code verändert werden, aber der Aufwand für die Regressionstests liegt bei mindestens einer Woche."
Es gibt Änderungen, die haben einen weitreichenden Einfluss auf das gesamte Softwaresystem; man nehme nur mal die Umstellung auf das IBAN-Format für Bankkontonummern. Um eventuelle Nebeneffekte ausschließen zu können, muss nach der Implementierung das gesamte System überprüft werden. Ohne Testautomatisierung kann der Aufwand dafür immens hoch liegen. Im schlimmsten Fall existiert noch nicht einmal eine Testfalldokumentation und die Abdeckung aller Anwendungsfälle bleibt dem Zufall überlassen. Nachbesserungen sind dann oft die Folge.
Variante 3: "Da müssen wir erst einmal analysieren, an welcher Stelle wir ansetzen müssen."
Diese Antwort taucht meist auf, wenn ein unerwünschtes Verhalten (aka Bug) behoben werden soll. Meist kann die Ursache für einen beobachteten Fehler in mehreren Teilkomponenten des Systems liegen. Verfügen diese Module über keine eigenen, dedizierten Tests, mit denen sich ihr Verhalten einzeln überprüfen lässt, bleibt den Entwicklern häufig nur der sehr zeitintensive Weg, die Wurzel des Übels am laufenden System mittels Debuggingwerkzeugen zu suchen. Je schwerer das Testszenario zu reproduzieren ist, umso aufwändiger wird dieses Verfahren. Eine einigermaßen stichhaltige Abschätzung des erwarteten Aufwandes ist meist nicht möglich.
Für alle diese Szenarien bietet die Testgetriebene Entwicklung eine Lösung. Sie schafft es durch die hohe Testabdeckung einen Rahmen zu schaffen, in dem jede Komponente gefahrlos erweitert und umstrukturiert werden kann. Nebeneffekte von Änderungen können dank Testautomatisierung in kürzester Zeit entdeckt werden. Und last but not least können durch die komponentenbezogenen Testfälle Fehlerursachen schneller und einfacher lokalisiert werden.
Alle diese Effekte bewirken eine effizientere Produktentwicklung und sorgen dafür, dass Änderungen auch nach Jahren der Weiterentwicklung mit unveränderter Geschwindigkeit umgesetzt werden können.
Wenn ihr mehr über Trainings und Einführungskonzepten zur Testgetriebenen Entwicklung erfahren wollt, stehe ich euch gerne als Ansprechpartner zur Verfügung. Ich freue mich auf euer Feedback!