Nach einer Umfrage von Martinig & Associates ist der Einsatz testgetriebener Entwicklung zwischen 2006 und 2008 von 14% auf 20% der befragten Organisationen gestiegen. Das ist auf der einen Seite erfreulich, auf der anderen Seite zeigt es aber, dass wir noch immer bei den „Early Adoptern“ sind. Daran gemessen, dass TDD im Gegensatz zu informellem „Nachtesten“ bei gleichem oder sogar verringertem Aufwand fast die doppelte Testabdeckung erreicht (persönliche Erfahungen sowohl von mir als auch von Johannes Link), dürfte die geringe Nutzung weder an wirtschaftlichen noch an methodischen Gründen liegen. Ich vermute eher, dass viele Entwickler sich zunächst subjektiv langsamer fühlen, wenn sie testgetrieben arbeiten — und nicht das Durchhaltevermögen haben, sich einmal zwei oder drei Monate auf das Verfahren einzulassen, bevor sie aufgeben. Dann würden Sie nämlich feststellen, dass sie deutlich weniger Fehler beheben müssen und damit wesentlich schneller sind, als vorher. Vielleicht nicht bis zu ersten „hingerotzten“ Version, aber sicher bis zum produktionsfähigen Code. Nur wenige Teams schaffen dieen Schritt denn auch aus eigener Kraft ohne Coaching.

Häufig wird testgetriebene Entwicklung von jenen in Frage gestellt, die sich eigentlich besonders über vermehrtes Testen freuen müssten: Professionellen Testern und Qualitätssicherer. Es sei widersinnig, wenn Entwickler auch Tests für ihren eigenen Code schrieben, bemerken Sie – korrekter Weise. Das wird von dem agilen Testansatz aber auch gar nicht in Frage gestellt, ebenso wenig, wie agile Ansätze eine eigene Testtruppe obsolet machen würden.

Tatsächlich halten sich die verbreiteten agilen Ansätze eher bedeckt, wenn es um die klassischen Testaufgaben geht. Ich persönlich orientiere mich in diesen Fragen stark an den Ideen von Brian Marick (http://www.exampler.com), der seit langer Zeit als Testconsultant arbeitet und dort agile Ansätze voran treibt. Er ist Co-Autor des agilen Manfiests und war mehrere Jahre Präsident der Agile Alliance Non-Profit Organisation (http://www.agilealliance.org).

Brian Marick kategorisiert die Testarten in agilen Projekten entlang zweier Dimensionen. Zum einen anhand ihrer Intention:
Weiterlesen →

Ein kurzer Hinweis auf Martin Fowler’s Blog-Eintrag „Test Cancer“ sei mir hier erlaubt. Er beschreibt das Phänomen, dass man nach einiger Zeit seinen Code einmal wieder sieht und ein guter Teil der Tests auskommentiert sind, oder nicht mehr laufen. Der lesenswerte Eintrag entspricht dem, was auch ich meinen Kunden immer wieder predige: Nur wenn alle Tests zu 100% laufen, sind die Testfälle das Sicherheitsnetz, das man benötigt, um sicher Software zu testen.

In diesem Sinne sind agile Verfahren Hoch-Disziplin-Methoden. Am ehesten erreicht man dieses Ziel, wenn man alle Tests im Buildserver laufen lässt und mehrmals täglich verifziert. Dann kann die Änderung, die zum Brechen des Tests geführt hat, relativ schnell identifziert werden.

Ein Entwickler beschwerte sich neulich bei mir, durch eine Änderung von Kollegen an der Testinfrastruktur habe er sieben Stunden lang die Tests nicht laufen lassen können, das sei die Hölle gewesen und hätte ihn letztlich zwei Überstunden gekostet. Er verlange, dass die Tests in Zukunft lauffähig bleiben. Diese Einstellung ist das beste Mittel gegen Testfall-Erosion, eine der Todsünden agiler Entwicklung.