1 Einleitung
In diesem Buch gebe ich eine Einführung für Einsteiger in das Verfahren, das als Akzeptanztest-getriebene Entwicklung (engl. Acceptance Test-Driven Development, kurz ATDD) bekannt wurde. Als ich 2008 das erste Mal mit dem Begriff ATDD konfrontiert wurde, wirkte es auf mich konstruiert und unnötig. Es erschien mir überflüssig, da ich ja 2008 schon die testgetriebene Entwicklung erlernt hatte und mir das völlig ausreichend vorkam. Und überhaupt, warum sollte ich auf Akzeptanzkriterien testen?
»O tempora, o mores«. Vier Jahre später schreibe ich nun selbst ein Buch über das, was man nun als Akzeptanztest-getriebene Entwicklung kennt. 2009 traf ich in London Gojko Adzic, der mir ein Exemplar seines Buchs Bridging the Communication Gap [Adz09] in die Hand drückte. Als ich es gleich auf der Heimreise zu Ende gelesen hatte, hatte ich eine Vorstellung von ATDD und wusste, warum man diesen Begriff meiden sollte.
Warum habe ich den Stoß Papier1 in Ihren Händen dennoch ATDD in der Praxis genannt?
Über den Begriff
ATDD kennt man schon eine ganze Weile, aber nicht nur unter dieser einen Bezeichnung. Das gleiche Verfahren kennt man auch unter anderen Namen. Hier eine unvollständige Liste:
Akzeptanztest-getriebene Entwicklung
Verhaltensgetriebene Entwicklung (Behavior-Driven Development: BDD)
Specification-by-Example
Agile-Acceptance-Testing
Story-Testing
Meiner Ansicht nach hat jede dieser Bezeichnungen Nachteile. Die Bezeichnung »Akzeptanztest-getriebene Entwicklung« vermittelt die Vorstellung, dass wir mit der Iteration schon fertig wären, wenn nur der Akzeptanztest erfolgreich durchläuft. Das stimmt so nicht, da jede Konstellation von Tests nicht alles abdecken kann. Im Netz der Tests gibt es immer Lücken. In der Welt des Testens ist man sich immer bewusst, dass man nicht alles testen kann. Allerdings wissen wir, wie Michael Bolton es einmal formuliert hat, dass wir auf gar keinen Fall mit der Arbeit fertig sind, wenn ein Akzeptanztest fehlgeschlagen ist.
Statt nun hier über die verschiedenen Bezeichnungen zu diskutieren, habe ich beschlossen eine Auswahl möglicher Alternativen anzubieten, um den Leser entscheiden zu lassen, welche ihm am besten passt. Unter dem Strich ist es unerheblich, wie man es nennt, solange es funktioniert. Die Welt der Softwareentwicklung ist voll von missverständlichen Ausdrücken und das wird bestimmt auch noch einige Jahre so bleiben. Software-Engineering, Testautomatisierung und Testgetriebene Entwicklung sind alle auf die eine oder andere Weise irreführend. Wie bei jeder Abstraktion sollte man den Begriff nicht mit dem Gegenstand verwechseln. Die Experten wissen um die Begrenztheit der Begriffe dieser Ansätze.
Aber was ist, wenn es mehrere Bezeichnungen für einen ähnlichen Ansatz gibt? Die von Ihnen verwendeten Verfahren mögen sehr wohl davon abweichen. Nachdem ich nun schon mehrere Teams in verschiedenen Unternehmen aufgesucht und beraten habe, ist mir aufgefallen, dass sie alle eines gemeinsam hatten: Jedes unterschied sich vom anderen. Während die Vorgehensweise Ihres Teams in Ihrer momentanen Firma wunderbar funktioniert, kann sie in einer anderen drastisch fehlschlagen. Haben Sie sich jemals über die Antwort des Beraters gewundert, wenn er mal wieder sagt »kommt darauf an«? Darin liegt der Grund.
Im Rahmen seines Buchs Specification by Example [Adz11] hat Gojko Adzic über fünfzig Teams befragt, die ATDD in der einen oder anderen Form anwenden. Dabei fand er eine ganze Reihe unterschiedlicher Verfahren heraus, die den ATDD-Ansatz begleiten. Alle Teams, die ATDD erfolgreich anwenden, beginnen mit einem grundlegenden Ansatz, werfen nach einiger Zeit einen Blick darauf und passen ihn dann anhand der eigenen Bedürfnisse im jeweiligen Kontext an. Eine sehr agile Vorgehensweise bei der Erprobung eines Ansatzes ist, wenn Sie mit einem sehr leichtgewichtigen Prozess einsteigen und dann neue Dinge anpassen, sobald sich Probleme ergeben. Bei der Anwendung von ATDD sollten Sie nicht vergessen, dass Ihr erstes Bündel an Verfahren aller Wahrscheinlichkeit nach nicht alle Ihre Probleme löst. Mit der Zeit werden Sie den Lösungsweg anpassen, wobei Sie immer mehr Erfahrungen sammeln.
Warum noch ein Buch über ATDD?
Während Gojko schon viele Muster erfolgreicher ATDD-Implementierungen beschrieben hat, klafft meiner Meinung nach bis jetzt noch eine Riesenlücke in den Büchern über ATDD. Es gibt einen großen Unterschied zwischen fortgeschrittenen Anwendern einer Fertigkeit oder eines Ansatzes und dem Anfänger darin.
Als ich die Literatur über ATDD durchging, fand ich mehrere Bücher, die Fortgeschrittene ansprachen und ihnen ATDD durch Verweis auf erfolgreiche Anwendungen erklärten. Für diese Lesergruppe ist es relativ einfach, diese Beispiele auf ihr eigenes Umfeld zu übertragen. Für den Anfänger auf diesem Gebiet trifft das allerdings nicht zu. Der Anfänger braucht konkrete Anleitungen, damit er loslegen kann. Wenn jemand anhand der Grundlagen erst einmal Erfahrungen gesammelt hat, kann er oder sie sich langsam von den engen Begrenzungen der Methode lossagen.
Anfänger lernen am besten, indem sie ein Rezept befolgen, und doch ist dieses Buch kein Kochbuch zu ATDD. Durch die Beispiele in diesem Buch vermittle ich zwei funktionierende Wege zu ATDD und beschreibe die Überlegungen der beteiligten Personen. Der Anfänger kann dies nutzen, um mit dem Einsatz von ATDD in seinem Team einzusteigen. Im Verlauf gebe ich außerdem noch Hinweise auf weiterführende Literatur.
Die Grundidee dieses Buchs entspringt dem Buch Test-Driven Development by Example von Kent Beck. Auch Beck liefert zwei funktionierende Beispiele Testgetriebener Entwicklung und erklärt im Anschluss die zugrunde liegenden Prinzipien. Das Buch war als Einsteigerbeschreibung zu TDD gedacht und liefert dem Anfänger für die ersten Schritte ausreichend Material – davon ausgehend, dass TDD mittels Reflexion und Übung erlernbar ist. Das Gleiche gilt im gewissen Umfang auch für dieses Buch.
Fachbegriffe
In diesem Buch werde ich immer wieder Begriffe aus der Welt der Agilen Softwareentwicklung verwenden. Da sicher nicht jeder Leser mit der Agilen Softwareentwicklung vertraut ist, ist an dieser Stelle eine kurze Einführung in diese Begriffe nötig.
Product-Owner:
In der Agilen Methode Scrum werden drei Rollen festgelegt: das Entwicklerteam, der Scrum-Master und der Product-Owner. Der Product-Owner ist für den Erfolg des Produkts, das das Team herstellt, verantwortlich. Er oder sie setzt die Prioritäten für die Features, die das Team implementieren soll und arbeitet mit den Stakeholdern zusammen, um diese herauszuarbeiten. Er oder sie vertritt also den Kunden im Team und entscheidet in dieser Funktion auch über Details, die er mit den Stakeholdern verhandeln muss.
Iteration oder Sprint:
Die Agile Softwareentwicklung beruht auf einem regelmäßigen Zyklus, der Iteration, bei Scrum auch Sprint genannt. Während dieser kurzen Arbeitsphasen implementiert das Team eine neue Ausbaustufe des Produkts, das im Prinzip auslieferbar ist. Die üblichen Iterationsintervalle liegen zwischen einer und vier Wochen.
User-Story:
Die User-Story ist ein begrenzter Umfang von Funktionalität, von dem das Team den Eindruck hat, es könne innerhalb einer Iteration implementiert werden. Sie bezeichnet einen sehr kleinen Abschnitt des Produkts. Im Normalfall ist das Team bestrebt, mehrere dieser User-Stories innerhalb einer Iteration zu implementieren. Für die Festlegung der User-Stories ist der Kundenvertreter, respektive Product-Owner, verantwortlich.
Taskboard:
Die meisten mit Agilen Methoden arbeitenden Teams planen ihre Arbeit auf einer Tafel, die für jedermann sichtbar ist. Sie benutzen dazu Kärtchen, um anzuzeigen, woran sie gerade arbeiten. Das Taskboard hat in der Regel mehrere Spalten, zumindest ToDo (ToDo), In Arbeit (Doing) und Erledigt (Done). Im Verlauf der Arbeit werden die Fortschritte auf dem Taskboard aktualisiert.
Story-Card:
Die User-Stories werden normalerweise auf Kärtchen geschrieben, die während der Iteration auf dem Taskboard des Teams angebracht sind.
Standup-Meeting, Daily Scrum:
Mindestens täglich bringen sich die Mitglieder des Teams gegenseitig auf den neuesten Stand der Iteration. Das Team trifft sich dazu eine Viertelstunde lang und bespricht, wie es die zu erledigenden Aufgaben (Tasks) bis zum Ende der Iteration bewältigen kann.
Product-Backlog, Sprint-Backlog:
Bei Scrum organisiert der Product-Owner die noch nicht implementierten User-Stories in einem Product-Backlog. Er oder sie ist für die Aktualisierung des Backlogs verantwortlich, sobald neue Anforderungen an das Produkt eintreffen. Wenn sich das Team zur Planung des nächsten Sprints zusammensetzt, erstellt es für diesen einen eigenen Backlog – den Sprint-Backlog. Die dabei ausgewählten User-Stories werden automatisch Teil des Sprint-Backlogs. Der Sprint-Backlog wird nach dem Planungstreffen meistens auf dem Taskboard...
