In der letzten Zeit erhalte ich viele Anfragen nach Material und Informationen zu ATDD. Solange mein Buch für Einsteiger über ATDD noch nicht veröffentlicht ist, muss ich stets auf ein paar Materialien von Kollegen verweisen. Damit ich auch mal was eigenes habe, worauf ich verweisen kann, dachte ich mir, schreibe ich mal einen Blogeintrag.
Bei Akzeptanztestgetriebener Entwicklung (ATDD) geht es darum, einen leichtgewichtigen Ansatz für die Spezifikation in Agilen Projekten zu haben. Doch ATDD geht noch darüber hinaus. Es geht ebenfalls darum, diese Spezifikation zu automatisieren, so dass sie als Akzeptanztest für die Software nach der Entwicklung dient. Statt eines toten Dokumentes für die Spezifikation entsteht somit eine ausführbare Spezifikation des Systems. Durch häufige Ausführung der entstandenen Tests entsteht insgesamt eine lebendige Dokumentation. Lassen Sie mich dieses theoretische Grundgerüst mit ein wenig Leben füllen.
Vor Beginn einer Iteration sprechen die Teammitglieder mit dem ProductOwner in Scrum oder dem Kunden in Kanban und XP über die kommenden Funktionalität. Dabei ist wichtig, dass in dieses Gespräch möglichst diverse Blickwinkel eingebunden werden. Programmierer sind dabei genau so wichtig wie Tester und Business Analysten. Es geht darum, ein gemeinsames Verständnis der Software zu entwickeln, und das klappt nunmal am besten im Team.
Aber was ist mit der Unabhängigkeit von Testern? Sollten die nicht möglichst nichts mit den Programmierern zu tun haben? Nur weil Tester ein Teil der Konversation zu der Spezifikation der Software sind, heißt das noch lange nicht, dass diese ihre Unabhängigkeit deswegen aufgeben. In traditionellen Projekten lesen sie schließlich auch die gleichen Dokument wie die Programmierer und kommen zu ganz anderen Rückschlüssen. Wenn Tester aber früh in das Projekt eingebunden werden können, dann können sie ihren wertvollen Input von Beginn an liefern und so zum gemeinsamen Verständnis und Aufdecken versteckter Annahmen beitragen.
Für die Organisation dieser Spezifikationsmeetings gibt es verschiedene Herangehensweisen. Ob Sie einen Tester, einen Programmierer und den Kunden zu einem Termin zusammenkommen lassen, oder ob Sie das gesamte Team in den Prozess einbinden, ist meisten Geschmacksache. Im Zweifelsfalls sollten Sie einen Ansatz, der Ihnen am besten zusagt ausprobieren, und über die Zeit mit Ihren Erfahrungen ggf. anpassen. Das gleiche Prinzip gilt für die Terminsetzung dieser Spezifikationsworkshops. Bei manchen Team genügt es, sich zwei Tage vor dem Sprint auszutauschen, bei anderen Teams ist eine Woche vorher gerade richtig. Auch hier gilt, Erfahrungen sammeln und den Prozess anpassen, wenn er nicht funktioniert.
Die Zeit zwischen Spezifikationsworkshop und Planungsmeeting kann der Kunde oder ProductOwner dann dafür nutzen, noch offene Fragen zu klären. Aber auch das Team sitzt nicht untätig herum. Tester können die identifizierten Beispiele nach dem Spezifikationsworkshop noch zu verfeinern und weitere Beispiele vorzubereiten. Die Programmierer können nochmal in den Code schauen, um ein klares Bild für das Planungsmeeting zu erhalten, ob die neue Funktion in der kommenden Iteration eingebaut werden kann, oder die dafür zur Verfügung stehende Zeit zu gering ist.
Während des Sprints arbeitet das Team gemeinsam daran, die Beispiele zu automatisieren. Dabei hilft die Expertise der Tester, die Geschäftssicht zu behalten. Die Expertise der Programmierer hilft dabei, die Tests auch wartbar zu automatisieren. Für den Fall, dass Tester bislang nur manuell getestet haben, ist dies somit kein Hindernis. Die Unabhängigkeit der Tester bleibt ebenfalls gewahrt, denn die Beispiele, die zuvor mit dem Kunden abgestimmt wurden, bleiben ja erhalten.
Doch mit welchen Tools erreiche ich das? Für die Toolfrage gibt es eine Menge Antworten. Generell gilt, dass ich so gut wie jedes Tool dafür nehmen kann. Angefangen bei xUnit über speziellere Tools wie FitNesse, Robot Framework oder Cucumber gibt es eine Reihe sog. Agil-freundlicher Testautomatisierungsframeworks. Wer einen Einblick in die unterschiedlichen Herangehensweisen haben möchte, kann sich die unterschiedlichen Frameworks im Triangle-Test-Sampler ansehen. Dort sind Tests für eine Applikation in unterschiedlichen Frameworks realisiert. Bei der Wahl gilt, dass am besten das ganze Team bestehend aus Programmierern, Testern und Kunden diese Entscheidung mit fällen sollten – denn im Zweifelsfall haben alle diese Entscheidung mit zu tragen.
Doch wie hält man diese Beispiele wartbar? Nun, bei Testautomatisierung gelten die gleichen Regeln wie bei Softwareentwicklung. Das bedeutet, dass Codeduplikation etwas böses ist, und ich auch nach meinen Tests wieder aufräumen muss. Hierfür sehe ich derzeit ein paar Refaktorisierungen, die die verschiedenen Tools bieten. Ein Beispiel ist das Extrahieren von Variablen, von Keywords aber auch das Einführen von Parametern, um mehr Tests über das gleiche Keyword automatisieren zu können. Wie beim Programmieren auch glaube ich, dass es weitere Refaktorisierungen gibt, die sich aus diesen Basis-Refaktorisierungen zusammensetzen.
Insgesamt gilt für ATDD, dass es nicht auf das Tool ankommt, sondern den Ansatz. Wie zuvor schon angedeutet sollten Sie mit einem Ansatz starten, der möglichst leicht für Sie umzusetzen ist, und diesen über Ihre Erfahrungen über die Zeit anpassen.
Bei Bedarf kann ich gerne auf weiterführende Bücher und Artikel verweisen.
