Die verhaltensgetriebene Entwicklung (BDD) ist ein Softwareentwicklungsansatz, bei dem drei Dinge im Vordergrund stehen: ein besseres Verständnis der Anforderungen, eine bessere Verifizierung dieser Anforderungen und eine bessere Dokumentation des erwarteten Verhaltens. Die Teams erreichen dies, indem sie gemeinsam konkrete Beispiele durcharbeiten, die als lesbare Wenn-dann-Szenarien geschrieben werden. Diese Szenarien dienen dann als ausführbare Spezifikationen, die mit Tools wie Cucumber, SpecFlow oder Req’n’Roll automatisiert werden können.
Das Wichtigste in Kürze
- BDD-Szenarien wie “Wenn-dann” sind nicht der Ausgangspunkt, sondern das dokumentierte Endergebnis eines kollaborativen Entdeckungsprozesses, an dem die geschäftlichen und technischen Rollen gemeinsam beteiligt sein müssen.
- Teams, die das gemeinsame Finden von Beispielen auslassen und eine Person allein Szenarien schreiben lassen, reproduzieren dieselbe Kommunikationslücke, die BDD schließen soll.
- Ein Szenario nach dem anderen zu implementieren, bevor man mit dem nächsten beginnt, führt zu einem besseren endgültigen Design als die Ausarbeitung der gesamten Lösung im Voraus, da die Anforderungen den Code direkt beeinflussen.
- Mit lesbaren BDD-Szenarien können sich Produktverantwortliche täglich selbst einen Überblick über den Stand der Umsetzung verschaffen, ohne auf eine Sprint-Demo oder ein Status-Update von den Entwicklern warten zu müssen.
Was ist verhaltensgetriebene Entwicklung?
Die verhaltensgetriebene Entwicklung ist ein Softwareentwicklungsansatz, der auf drei Ziele ausgerichtet ist: ein besseres Verständnis der Anforderungen, eine bessere Verifizierung dieser Anforderungen und eine bessere Dokumentation des erwarteten Verhaltens. Das Wort “Verhalten” verweist auf den letzten Teil, der beschreibt, wie sich das System verhalten soll.
Das sichtbarste Artefakt des BDD ist das Szenario. Dabei handelt es sich um textuelle Beschreibungen eines Verhaltens, die mit Wenn-dann-Schlüsselwörtern geschrieben werden und typischerweise mit Tools wie Cucumber, SpecFlow oder Rack’n’Roll verwendet werden.
Gáspár Nagy, der Erfinder von SpecFlow und Rack’n’Roll, stellt die Methode auf die Lücke ab, die die meisten Teams gut kennen: den Abstand zwischen einem Gedanken in einer Anforderung und seiner technischen Umsetzung. An dieser Stelle geht das Verständnis verloren. BDD soll diese Lücke schließen, bevor der Code geschrieben wird.
Warum Beispiele sorgfältig geschriebene Spezifikationen schlagen
Menschen verstehen komplexe Themen durch Beispiele, nicht durch abstrakte, isoliert gelesene Spezifikationen. So lernen Menschen im Allgemeinen, und Software ist da keine Ausnahme.
Gáspár zieht den Fußball als Vergleich heran. Niemand lernt das Spiel, indem er zuerst das Regelbuch liest. Sie gehen auf das Spielfeld, sehen zu, wie andere spielen, und machen sich das Spiel zu eigen. Später, wenn sie ein Gefühl dafür haben, folgen die abstrakten Regeln und die offenen Fragen. Das Beispiel kommt zuerst, die Spezifikation unterstützt es.
Die Softwareentwicklung hat das stillschweigend vergessen. Es herrscht der Glaube vor, dass die Menschen das Problem verstehen und die richtige Lösung bauen werden, wenn du die Spezifikation sorgfältig genug schreibst und jedes Wort mit Präzision wählst. Gute Spezifikationen sind wertvoll, aber sie sind keine Garantie für ein gemeinsames Verständnis.
Um sicherzugehen, dass alle dieselben Wörter auf dieselbe Weise gelesen haben, muss ein Team gemeinsam daran arbeiten. Konkrete Beispiele machen das möglich. Ein Team kann sich eines ansehen und sagen: Ja, so haben wir uns das Verhalten der Anwendung vorgestellt, wenn sie einmal gebaut ist.
Wie ein Wenn-dann-Szenario eine Regel erfasst
Ein BDD-Szenario ist ein ordentlich aufgeschriebenes Beispiel für ein einzelnes Verhalten. Die gegeben-wenn-dann-Struktur macht aus einem informellen Beispiel etwas Präzises.
Nehmen wir ein Bankbeispiel. Angenommen, ich habe 20 Dollar auf meinem Konto. Wenn ich versuche, 100 Dollar am Geldautomaten abzuheben, wird die Transaktion abgelehnt, weil ich nicht genug Geld habe. Dieses einzelne Szenario verdeutlicht eine Regel: Du kannst nur so viel Geld abheben, wie du hast.
Die erste Reaktion ist normalerweise, dass ein solches Beispiel trivial ist. Diese Reaktion geht an der Sache vorbei. Wenn du weitere Beispiele anführst, lösen einige von ihnen scharfe Fragen aus. Was genau bedeutet “versuchen, Geld abzuheben”? Diese Diskussionen bringen die kleinen Details zum Vorschein, die später in der Entwicklung Probleme verursachen. Die Trivialität ist der Einstiegspunkt, nicht die Grenze.
Beispiele werden gemeinsam geschrieben, nicht übergeben
Szenarien entstehen durch Zusammenarbeit, nicht durch Delegation. Das ist der Unterschied, der darüber entscheidet, ob BDD einen Mehrwert liefert oder nur eine weitere Möglichkeit ist, Tests zu speichern.
Die Fehlerwirkung ist vorhersehbar. Ein Produktverantwortlicher schreibt allein zwanzig Szenarien, gibt sie an das Team weiter und bittet es, wiederzukommen, wenn es fertig ist. Damit steht das Team wieder vor dem ursprünglichen Problem: etwas, das nur aus der Unternehmensperspektive geschrieben wurde, ohne dass überprüft wurde, ob das Team es auch so verstanden hat.
Das Verständnis muss gemeinsam erarbeitet werden. Die Leute setzen sich zusammen, schauen sich eine Geschäftsregel an und fragen, welche Beispiele sie sich dafür vorstellen können. Manchmal reichen ein oder zwei Beispiele, um die Regel in einer Minute zu klären, weil alle sie bereits auf dieselbe Weise gelesen haben. Manchmal zeigt die Diskussion, dass die Regel selbst nicht ganz richtig ist und geändert werden muss.
Zusammensitzen, auch virtuell, fühlt sich in einer auf Effizienz optimierten Welt teuer an. Es ist eine Investition, die sich auszahlt. Ohne den gemeinschaftlichen Schritt wird der Wert nicht sichtbar.
Du brauchst keine aufwendige Zeremonie, um dorthin zu gelangen. Das Mapping von Beispielen ist eine Methode, um die Zusammenarbeit zu erleichtern. Feature Mapping ist eine andere. Manche Teams erfinden ihre eigene. Die Mechanik ist einfach; was zählt, ist das gemeinsame Gespräch.
Der einfachste Einstiegspunkt ist eine unschuldige Frage
Du kannst mit der Anwendung von BDD beginnen, ohne es zu benennen. Die erste Stufe ist, in jeder Diskussion über Anforderungen zu fragen: “Könnten Sie uns bitte ein Beispiel nennen?”
Gáspár beschreibt, wie es in seinen eigenen Teams begann. In Meetings, in denen die Details der User-Storys besprochen wurden, kamen sie immer wieder auf diese eine Frage zurück. Sie braucht keine Werkzeuge und keine Theorie. Sie fühlt sich natürlich an und wenn man sie oft genug benutzt, erledigt sie die meiste Arbeit von selbst.
Dies ist auch die sauberere Version von Shift-Left. Das Gespräch findet am frühesten Punkt statt, an dem das gemeinsame Verständnis die Grundlage für alles Weitere bildet. Ein besseres Verständnis führt zu besseren Tests, weniger Nacharbeit und einem Endergebnis, das näher an den Wünschen des Kunden liegt.
Wie aus Szenarien ausführbare Spezifikationen werden
Sobald Szenarien existieren, machen die Werkzeuge der Cucumber-Familie sie lauffähig. Es gibt keine magische Übersetzung von englischen Sätzen in Automatisierungscode.
Der Mechanismus ist konkret. Für jede Art von Schritt sagst du dem Werkzeug, wie er automatisiert werden soll. Für einen Schritt wie “Ich versuche, 100 Dollar am Geldautomaten abzuheben”, schreibst du einen kleinen Automatisierungsblock. Für “die Transaktion schlägt fehl” schreibst du einen anderen. Das Tool liest dann ein Szenario, setzt die passenden Blöcke zusammen und erstellt einen ausführbaren Test.
Das ist die Idee einer ausführbaren Spezifikation. BDD ist eine Umsetzung dieser Idee. Die geschriebene Spezifikation kann nun ausgeführt werden, und wenn die Szenarien bestanden werden, ist die Wahrscheinlichkeit hoch, dass sich das System in die richtige Richtung bewegt.
Ein grobes Gefühl für den Maßstab hilft. Eine durchschnittliche User-Story gliedert sich in drei oder vier Akzeptanzkriterien. Zu jeder Regel gibt es ein bis drei Beispiele. Das bedeutet, dass eine User-Story etwa zehn bis fünfzehn Szenarien umfasst.
Diese Szenarien sind nicht die gesamte Testsuite. Gáspár vergleicht sie mit den Ankerpunkten eines Sicherheitsnetzes. Sie decken die Eckpfeiler ab und halten das Verständnis der Anforderungen fest. Zum richtigen Testen braucht es noch viele weitere Testfälle.
Szenarien sollten die Umsetzung vorantreiben, eins nach dem anderen
Das “getrieben” in verhaltensgetriebener Entwicklung ist wörtlich zu nehmen: Szenarien sollten den Aufbau steuern, Szenario für Szenario. Die empfohlene Praxis ist, nicht den ganzen Code zu schreiben und am Ende zu prüfen, ob alles grün wird.
Nimm stattdessen das erste und einfachste Beispiel, eine erfolgreiche Abhebung, und schreibe Code, bis sie bestanden ist. Das Ergebnis ist halbfertig, aber ein Szenario ist grün. Nimm dann das nächste, vielleicht eine Abhebung einer negativen Zahl, und implementiere die richtige Fehlhandlung. Mach weiter mit dem nächsten und dem übernächsten.
Wenn jedes Szenario für eine User-Story bestanden ist, ist die Lösung für diese User-Story fertig. Das beantwortet eine Frage, die Projekte seit Jahren verfolgt: Wann kann man sagen, dass etwas fertig ist? Die endlosen “Sind wir bei 70 Prozent oder 80 Prozent?”-Diskussionen, bei denen sich die ehrliche Antwort als 20 Prozent herausstellte, verlieren ihren Schrecken. Der Fortschritt wird sichtbar und vorhersehbar.
Es gilt, mentale Widerstände zu überwinden. Warum eine halbgare Version bauen, wenn du schon weißt, dass eine negative Prüfung kommt? Wenn du dich durchsetzt, nimmt die Umsetzung anhand der Anforderungen Gestalt an und nicht anhand eines im Voraus entworfenen Designs. Der endgültige Entwurf fällt oft besser aus als das, was du in einem Rutsch durchgespült hättest.
Das ist das gleiche vertikale Slicing wie bei der testgetriebenen Entwicklung. Der Unterschied ist die Ebene. Bei der testgetriebenen Entwicklung geht es um den technischen Aspekt. BDD befasst sich mit dem Aspekt der Anforderungen.
Wie BDD die geschäftliche und die technische Sicht verbindet
BDD schafft eine Verbindungsfähigkeit zwischen dem, was das Unternehmen will, und dem, was die Entwicklerinnen und Entwickler bauen, mit gemeinsamer Transparenz auf beiden Seiten. Die Szenarien sind lesbar, so dass der Product Owner den Fortschritt verfolgen kann, ohne Code übersetzen zu müssen.
Der Nutzen zeigt sich täglich. Ein Product Owner kann sehen, dass zehn Szenarien für eine User-Story geplant sind und drei bereits bestanden wurden. An einem Dienstagmorgen kann er diese drei Szenarien lesen, eine kurze manuelle Prüfung auf dem Demoserver durchführen und Feedback geben, bevor die ganze Geschichte fertig ist.
Damit wird auch der Mini-Wasserfall durchbrochen, der sich in vielen agilen Iterationen versteckt: erst planen, dann bauen, und dann alle Tests und die Automatisierung in die letzten zwei Tage packen. Bei der szenarioweisen Umsetzung fließt die Arbeit durch den Sprint, anstatt sich am Ende zu stapeln.
Das schlägt im Grunde eine Brücke zwischen den Anforderungen und den tatsächlichen technischen Assets, dem Code, den du tatsächlich baust. Ich finde, diese Metapher funktioniert ziemlich gut.
- Gáspár Nagy
Die gleiche Idee taucht auch unter anderen Namen auf. Testgetriebene Entwicklung, Spezifikation durch Beispiele, alle deuten auf dasselbe Konzept hin. Gojko Adzic hat ein frühes Buch über Spezifikation durch Beispiele mit dem Untertitel “bridging the communication gap” betitelt, und diese Brücke baut BDD.
Halte Spezifikationen und gewöhnliche Tests klar voneinander getrennt
Das Geben-wenn-dann-Prinzip gilt nicht nur für BDD, und die Wiederverwendung der Struktur für einfache Testfälle ist in Ordnung, solange du Verwirrung vermeidest. Die Struktur fühlt sich für jeden Tester natürlich an, da Testfälle bereits Vorbereitungsschritte, Aktionsschritte und Verifizierungsschritte haben.
Das Problem beginnt, wenn die Szenarien nicht mehr lesbar sind. Ein Szenario mit Geben-wenn-wenn-dann-dann-wenn-wenn ist keine Spezifikation mehr, die jemand validieren kann. Wenn zehn Leute zusammensitzen müssen, um zu entschlüsseln, was ein Szenario bedeutet, hat es seine Aufgabe verloren. Die geschäftliche Lesbarkeit ist es, die das Team bestätigen lässt, dass das Szenario das beschreibt, was sie wollten.
Es lohnt sich, die Trennung deutlich zu machen: BDD-Szenarien sind die Spezifikation, und die vielen Tests, die daraus gebaut werden, sind etwas anderes. Wenn du die Spezifikation missverstehst, erbt jeder daraus abgeleitete Test das Missverständnis.
Wenn Teams dieselben Werkzeuge für normale Testfälle verwenden, empfiehlt Gáspár eine klare Trennung. Lege sie in einem anderen Ordner ab. Kennzeichne sie mit einem Tag. Mach deutlich, dass es sich bei dem einen Satz um die Spezifikation und bei dem anderen um zusätzliche Tests handelt, damit sich niemand fragen muss, warum zwei Dinge, die gleich aussehen, unterschiedlich behandelt werden.
Wie ein .NET-Tool für Cucumber entstand
Die Werkzeuge haben BDD in die breite Praxis getragen. Aslak Hellesøy entwickelte 2008 Cucumber, und eine gute Automatisierungsunterstützung öffnete vielen Teams die Tür, auch wenn es im Kern um Anforderungen und Verständnis geht.
Gáspár lernte BDD 2009 in einem Projekt kennen, ein Jahr nachdem Cucumber erschienen war. Sein Team arbeitete an Microsoft .NET, während Cucumber für Ruby entwickelt wurde. Also portierten sie es auf .NET und veröffentlichten es als Open Source unter dem Namen SpecFlow. Er wurde zum Hauptverantwortlichen für das Projekt in seinem Unternehmen.
Später zog er sich von der Pflege von SpecFlow zurück, und der Name und die Codebasis wurden schließlich von ihrem Besitzer aufgegeben. Die Teams, die es noch benutzten, brauchten ein Tool, das mit dem aktuellen .NET Schritt hält. Vor etwa anderthalb Jahren forkte Gáspár den Code, kopierte die bestehende Basis und machte von dort aus weiter, was die Open-Source-Lizenzen erlauben.
Markenrechtliche Probleme erzwangen eine Umbenennung, so dass das Tool jetzt Rack’n’Roll heißt. Es ist die .NET-Implementierung von Cucumber und wird von einer Gruppe freiwilliger Mitarbeiter/innen gepflegt. Die Teams von Rack’n’Roll und Cucumber tauschen sich auf Discord aus, tragen zur Arbeit des jeweils anderen bei und tauschen Vorschläge für die beiden Projekte aus.
