Behavior Driven Development (BDD), auf Deutsch verhaltensgetriebene Entwicklung, ist ein Ansatz der Softwareentwicklung mit drei Zielen: Anforderungen besser verstehen, besser verifizieren und das erwartete Verhalten besser dokumentieren. Dafür erarbeiten Teams gemeinsam konkrete Beispiele und schreiben sie als lesbare Given-When-Then-Szenarien auf. Diese Szenarien dienen dann als ausführbare Spezifikation, automatisiert mit Tools wie Cucumber, SpecFlow oder Reqnroll.
Das Wichtigste in Kürze
- Given-When-Then-Szenarien sind nicht der Startpunkt von BDD, sondern das dokumentierte Ergebnis einer gemeinsamen Klärung, an der fachliche und technische Rollen zusammen beteiligt sein müssen.
- Wer das gemeinsame Finden von Beispielen überspringt und eine Person allein Szenarien schreiben lässt, baut genau die Kommunikationslücke wieder auf, die BDD schließen soll.
- Szenario für Szenario zu implementieren und jedes abzuschließen, bevor das nächste beginnt, führt zu einem besseren Design als eine im Voraus ausgearbeitete Gesamtlösung, weil die Anforderungen den Code direkt formen.
- Lesbare BDD-Szenarien zeigen Product Ownern jeden Tag selbst, wie weit die Umsetzung ist, ohne auf eine Sprint-Demo oder ein Status-Update der Entwickler zu warten.
Was ist Behavior Driven Development?
Die verhaltensgetriebene Entwicklung verfolgt drei Ziele: Anforderungen besser verstehen, sie besser verifizieren und das erwartete Verhalten besser dokumentieren. Das Wort “Behavior”, also Verhalten, steht für den letzten Punkt. Beschrieben wird, wie sich das System verhalten soll.
Das sichtbarste Artefakt von BDD ist das Szenario: eine textuelle Beschreibung eines Verhaltens, geschrieben mit den Schlüsselwörtern Given, When und Then und meist eingesetzt mit Tools wie Cucumber, SpecFlow oder Reqnroll.
Gáspár Nagy, der SpecFlow und Reqnroll geschaffen hat, richtet die Methode auf eine Lücke aus, die fast jedes Team kennt: den Abstand zwischen dem Gedanken in einer Anforderung und seiner technischen Umsetzung. Genau dort geht Verständnis verloren. BDD soll diese Lücke schließen, bevor Code entsteht.
Warum Beispiele sorgfältige Spezifikationen schlagen
Menschen verstehen komplexe Themen über Beispiele, nicht über abstrakte Spezifikationen, die man für sich allein liest. So lernen wir generell, und Software ist keine Ausnahme.
Gáspár vergleicht das mit Fußball. Niemand lernt das Spiel, indem er zuerst das Regelwerk liest. Man geht auf den Platz, schaut anderen zu und probiert es selbst. Erst wenn man ein Gefühl dafür hat, kommen die abstrakten Regeln und die offenen Fragen. Das Beispiel kommt zuerst, die Spezifikation stützt es.
Die Softwareentwicklung hat das stillschweigend vergessen. Verbreitet ist der Glaube: Wenn du die Spezifikation nur sorgfältig genug schreibst und jedes Wort genau wählst, verstehen alle das Problem und bauen die richtige Lösung. Gute Spezifikationen sind wertvoll, aber sie garantieren kein gemeinsames Verständnis.
Ob alle dieselben Wörter gleich gelesen haben, findet ein Team nur gemeinsam heraus. Konkrete Beispiele machen das möglich. Das Team schaut sich eines an und sagt: Ja, so haben wir uns das Verhalten der fertigen Anwendung vorgestellt.
Wie ein Gegeben-Wenn-Dann-Szenario eine Regel festhält
Ein BDD-Szenario ist ein sauber aufgeschriebenes Beispiel für genau ein Verhalten. Die Struktur Given-When-Then (auf Deutsch Gegeben-Wenn-Dann) macht aus einem lockeren Beispiel etwas Präzises.
Nehmen wir einen Fall aus dem Banking. Angenommen, ich habe 20 Dollar auf dem Konto. Wenn ich am Geldautomaten 100 Dollar abheben will, dann wird die Transaktion abgelehnt, weil das Guthaben nicht reicht. Dieses eine Szenario veranschaulicht eine Regel: Du kannst nur so viel abheben, wie du hast.
Die erste Reaktion lautet meist, so ein Beispiel sei trivial. Das geht am Punkt vorbei. Wer weitere Beispiele sammelt, stößt bei einigen auf scharfe Fragen. Was genau heißt “abheben wollen”? Solche Diskussionen bringen die kleinen Details ans Licht, die später in der Entwicklung Ärger machen. Die Trivialität ist der Einstieg, nicht die Grenze.
Beispiele entstehen gemeinsam, nicht per Übergabe
Szenarien entstehen in Zusammenarbeit, nicht durch Delegation. Daran entscheidet sich, ob BDD echten Nutzen bringt oder nur eine weitere Art ist, Tests abzulegen.
Das Scheitern folgt einem bekannten Muster. Ein Product Owner schreibt allein zwanzig Szenarien, gibt sie ans Team und sagt: Meldet euch, wenn ihr fertig seid. Damit steht das Team wieder vor dem Ausgangsproblem. Etwas ist nur aus fachlicher Sicht geschrieben, und niemand hat geprüft, ob das Team es genauso versteht.
Verständnis muss gemeinsam wachsen. Die Beteiligten setzen sich zusammen, nehmen sich eine Geschäftsregel vor und fragen, welche Beispiele ihnen dazu einfallen. Manchmal klären ein oder zwei Beispiele die Regel in einer Minute, weil alle sie ohnehin gleich gelesen haben. Manchmal zeigt die Diskussion, dass die Regel selbst nicht ganz stimmt und geändert werden muss.
Zusammensitzen, auch virtuell, wirkt in einer auf Effizienz getrimmten Welt teuer. Es ist eine Investition, die sich auszahlt. Ohne den gemeinsamen Schritt zeigt sich der Nutzen nicht.
Aufwendige Zeremonien brauchst du dafür nicht. Example Mapping ist eine Moderationstechnik, Feature Mapping eine andere, und manche Teams erfinden ihre eigene. Die Mechanik ist einfach. Entscheidend ist das gemeinsame Gespräch.
Der einfachste Einstieg ist eine harmlose Frage
Du kannst BDD anwenden, ohne es so zu nennen. Die erste Stufe: In jeder Diskussion über Anforderungen fragst du “Kannst du uns bitte ein Beispiel geben?”
So hat es nach Gáspárs Schilderung auch in seinen eigenen Teams angefangen. In den Meetings zu den Details der User Stories kamen sie immer wieder auf genau diese Frage zurück. Sie braucht keine Tools und keine Theorie. Sie fühlt sich natürlich an, und wer sie oft genug stellt, dem nimmt sie den Großteil der Arbeit ab.
Das ist auch die sauberere Form von Shift-Left. Das Gespräch findet zum frühestmöglichen Zeitpunkt statt, und das gemeinsame Verständnis wird zur Grundlage für alles Weitere. Besseres Verständnis bringt bessere Tests, weniger Nacharbeit und ein Ergebnis, das näher an dem liegt, was der Kunde wirklich wollte.
Wie aus Szenarien ausführbare Spezifikationen werden
Sobald es Szenarien gibt, machen die Tools der Cucumber-Familie sie lauffähig. Eine magische Übersetzung von englischen Sätzen in Automatisierungscode gibt es dabei nicht.
Der Mechanismus ist handfest. Für jede Art von Schritt sagst du dem Tool, wie es ihn automatisieren soll. Für einen Schritt wie “ich will am Geldautomaten 100 Dollar abheben” schreibst du einen kleinen Automatisierungsblock, für “die Transaktion schlägt fehl” einen weiteren. Das Tool liest dann ein Szenario, setzt die passenden Blöcke zusammen und erzeugt daraus einen ausführbaren Test.
Das ist die Idee der ausführbaren Spezifikation, und BDD ist eine Umsetzung davon. Die geschriebene Spezifikation läuft jetzt, und wenn die Szenarien grün sind, bewegt sich das System mit hoher Wahrscheinlichkeit in die richtige Richtung.
Ein grobes Gefühl für die Größenordnung hilft. Eine durchschnittliche User Story zerfällt in drei oder vier Akzeptanzkriterien, zu jeder Regel gibt es ein bis drei Beispiele. Eine User Story kommt so auf etwa zehn bis fünfzehn Szenarien.
Diese Szenarien sind nicht die komplette Testsuite. Gáspár vergleicht sie mit den Ankerpunkten eines Sicherheitsnetzes. Sie decken die Eckpfeiler ab und halten das Verständnis der Anforderungen fest. Für gründliches Testen braucht es darüber hinaus viele weitere Testfälle.
Szenarien treiben die Umsetzung, eines nach dem anderen
Das “Driven” in Behavior Driven Development ist wörtlich gemeint: Die Szenarien steuern den Aufbau, Szenario für Szenario. Nicht empfehlenswert ist es, erst den ganzen Code zu schreiben und am Ende zu schauen, ob alles grün wird.
Nimm stattdessen das erste und einfachste Beispiel, eine erfolgreiche Abhebung, und schreib Code, bis es durchläuft. Das Ergebnis ist halbfertig, aber ein Szenario ist grün. Dann kommt das nächste, vielleicht eine Abhebung mit negativem Betrag, und du implementierst die passende Fehlerbehandlung. Dann das nächste und das übernächste.
Sind alle Szenarien einer User Story grün, ist die Lösung für diese Story fertig. Damit ist eine Frage beantwortet, die Projekte seit Jahren verfolgt: Wann ist etwas wirklich fertig? Die endlosen Diskussionen “Sind wir bei 70 oder bei 80 Prozent?”, bei denen die ehrliche Antwort am Ende 20 Prozent lautete, verlieren ihren Schrecken. Der Fortschritt wird sichtbar und planbar.
Dafür musst du einen inneren Widerstand überwinden. Warum eine halbgare Version bauen, wenn du schon weißt, dass die Prüfung auf negative Beträge kommt? Wenn du dranbleibst, formt sich die Umsetzung an den Anforderungen und nicht an einem vorab entworfenen Design. Das Ergebnis ist oft besser als das, was du in einem Rutsch heruntergeschrieben hättest.
Worin sich BDD von testgetriebener Entwicklung unterscheidet
Das Vorgehen ist dasselbe vertikale Schneiden wie in der testgetriebenen Entwicklung (TDD). Der Unterschied liegt in der Ebene. TDD arbeitet am technischen Aspekt, BDD an den Anforderungen.
Wie BDD fachliche und technische Sicht verbindet
BDD verbindet das, was das Business will, mit dem, was die Entwickler bauen, und schafft auf beiden Seiten dieselbe Transparenz. Die Szenarien sind lesbar, der Product Owner kann den Fortschritt also verfolgen, ohne Code zu verstehen.
Der Nutzen zeigt sich jeden Tag. Ein Product Owner sieht, dass für eine User Story zehn Szenarien geplant sind und drei schon grün sind. An einem Dienstagmorgen liest er diese drei, prüft sie kurz manuell auf dem Demoserver und gibt Feedback, bevor die ganze Story fertig ist.
Das bricht auch den Mini-Wasserfall auf, der in vielen agilen Iterationen steckt: erst planen, dann bauen und alle Tests samt Automatisierung in die letzten zwei Tage quetschen. Wer Szenario für Szenario liefert, verteilt die Arbeit über den Sprint, statt sie am Ende aufzutürmen.
“Im Grunde schlägt das eine Brücke zwischen den Anforderungen und den tatsächlichen technischen Assets, also dem Code, den du wirklich baust. Ich finde, die Metapher funktioniert ziemlich gut.”
(Gáspár Nagy)
Dieselbe Idee taucht auch unter anderen Namen auf. Testgetriebene Entwicklung, Specification by Example, alles zielt auf dasselbe Konzept. Gojko Adzic hat einem frühen Buch über Specification by Example den Untertitel “Bridging the Communication Gap” gegeben, und genau diese Brücke baut BDD.
Spezifikation und gewöhnliche Tests sauber trennen
Given-When-Then gehört nicht BDD allein. Die Struktur für einfache Testfälle wiederzuverwenden ist in Ordnung, solange keine Verwirrung entsteht. Für Tester fühlt sie sich ohnehin natürlich an, denn Testfälle haben schon Vorbereitungs-, Aktions- und Prüfschritte.
Ärger beginnt, wenn Szenarien nicht mehr lesbar sind. Ein Szenario nach dem Muster Given-When-When-When-Then-Then-When-When ist keine Spezifikation mehr, die irgendwer validieren kann. Wenn sich zehn Leute zusammensetzen müssen, um ein Szenario zu entschlüsseln, hat es seinen Zweck verfehlt. Erst die fachliche Lesbarkeit erlaubt dem Team zu bestätigen, dass das Szenario beschreibt, was gewollt war.
Die Trennung verdient es, klar ausgesprochen zu werden: BDD-Szenarien sind die Spezifikation, die vielen daraus gebauten Tests sind etwas anderes. Wer die Spezifikation falsch versteht, vererbt das Missverständnis an jeden abgeleiteten Test.
Nutzen Teams dieselben Tools auch für normale Testfälle, empfiehlt Gáspár eine klare Trennung. Leg sie in einen anderen Ordner. Markier sie mit einem Tag. Mach deutlich, welcher Satz die Spezifikation ist und welcher zusätzliche Tests enthält, damit sich niemand wundert, warum zwei gleich aussehende Dinge unterschiedlich behandelt werden.
Wie ein .NET-Tool für Cucumber entstand
Die Tools haben BDD in die breite Praxis getragen. Aslak Hellesøy entwickelte 2008 Cucumber, und gute Unterstützung bei der Automatisierung ö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 nach dem Erscheinen von Cucumber. Sein Team arbeitete mit Microsoft .NET, Cucumber war für Ruby gebaut. Also portierten sie es auf .NET und veröffentlichten es als Open Source unter dem Namen SpecFlow. In seiner damaligen Firma wurde er zum Hauptmaintainer.
Später zog er sich aus der Pflege von SpecFlow zurück, und der Eigentümer gab Name und Codebasis schließlich auf. Die Teams, die es noch nutzten, brauchten aber ein Tool, das mit aktuellem .NET Schritt hält. Vor etwa anderthalb Jahren hat Gáspár den Code geforkt, also die bestehende Basis kopiert und dort weitergemacht, was Open-Source-Lizenzen erlauben.
Wegen markenrechtlicher Probleme musste das Tool umbenannt werden und heißt jetzt Reqnroll. Es ist die .NET-Implementierung von Cucumber und wird von einer Gruppe Freiwilliger gepflegt. Die Teams von Reqnroll und Cucumber tauschen sich auf Discord aus, arbeiten an den Projekten des jeweils anderen mit und teilen Vorschläge für beide.
Häufig gestellte Fragen
Stellen detaillierte schriftliche Spezifikationen sicher, dass jeder eine Anforderung auf dieselbe Weise versteht?
Nein. Eine sorgfältige Formulierung ist wertvoll, aber sie garantiert niemals, dass alle Leser dieselben Sätze auf dieselbe Weise interpretieren. Menschen begreifen komplexe Themen anhand von Beispielen: Niemand lernt Fußball, indem er zuerst das Regelwerk liest, man schaut sich ein Spiel an und versteht die abstrakten Regeln erst später. Ein konkretes Beispiel ermöglicht es einem Team, laut auszusprechen, wie es sich das Verhalten des Systems vorgestellt hat.
Wer sollte an der Erstellung von BDD-Szenarien beteiligt sein?
Geschäftliche und technische Rollen gemeinsam. Ein häufiger Fehler ist, dass ein Product Owner zwanzig Szenarien alleine schreibt, sie übergibt und das Team bittet, sich zu melden, wenn es fertig ist. Das reproduziert genau die Lücke, die BDD eigentlich schließen soll, denn es wurde nicht überprüft, ob das Verständnis des Teams mit den Szenarien übereinstimmt. Moderationstechniken wie Example Mapping oder Feature Mapping helfen zwar, aber was wirklich zählt, ist der gemeinsame Dialog.
Was ist der kleinstmögliche erste Schritt in Richtung verhaltensgetriebener Entwicklung?
Stell bei jeder Anforderungsbesprechung eine Frage: Könntest du uns bitte ein Beispiel nennen? Dafür braucht es weder Tools noch Frameworks noch spezielles Vokabular, und wenn man es oft genug anwendet, erledigt es den Großteil der Arbeit von selbst. Das ist auch die ehrliche Version von „Shift-Left“, da ein gemeinsames Verständnis schon zum frühestmöglichen Zeitpunkt aufgebaut wird und sich dann auf Tests, Nacharbeiten und das Endergebnis überträgt.
Wie viele „Given-When-Then“-Szenarien entstehen typischerweise bei einer einzelnen User-Story?
Ungefähr zehn bis fünfzehn. Eine durchschnittliche User-Story lässt sich in drei oder vier Akzeptanzkriterien unterteilen, und jede Regel enthält in der Regel ein bis drei Beispiele. Es lohnt sich, diesen Umfang zu kennen, bevor ein Team loslegt, denn so lassen sich Erwartungen hinsichtlich des Aufwands festlegen und es wird deutlich, dass die Szenarien auf der Ebene der Regeln bleiben, anstatt jede mögliche Eingabekombination abzudecken.
Ersetzen BDD-Szenarien die Testsuite eines Projekts?
Nein. Sie funktionieren wie die Ankerpunkte eines Sicherheitsnetzes: Sie decken die Eckpfeiler ab und sichern das gemeinsame Verständnis der Anforderungen. Für ein ordnungsgemäßes Testen braucht es darüber hinaus noch viele weitere Testfälle. Die beiden zu verwechseln ist riskant, denn eine falsch verstandene Spezifikation überträgt ihren Fehler auf jeden daraus abgeleiteten Test.
Wie unterscheidet sich BDD von testgetriebener Entwicklung?
Beide nutzen dasselbe vertikale Aufteilen: Man nimmt sich ein kleines Stück vor und schließt es ab, bevor man weitermacht. Der Unterschied liegt in der Ebene, auf der sie arbeiten. Testgetriebene Entwicklung befasst sich mit dem technischen Aspekt, BDD mit dem Anforderungsaspekt. Bei BDD implementierst du ein Szenario, bis es bestanden hat, dann das nächste. So wächst das Design aus den Anforderungen heraus, statt aus einer vorab erstellten Skizze.
Wie kann ein Product Owner den Implementierungsfortschritt verfolgen, bevor eine User-Story fertig ist?
Indem er die Szenarien direkt liest. Wenn für eine User-Story zehn Szenarien geplant sind und drei bereits bestanden sind, kann der Product Owner diese drei an einem Dienstagmorgen lesen, eine schnelle manuelle Überprüfung auf dem Demo-Server durchführen und Feedback geben, während der Rest noch entwickelt wird. Dazwischen sind weder eine Sprint-Demo noch ein Statusbericht der Entwickler nötig.
Wann funktioniert ein „Given-When-Then“-Szenario nicht mehr als Spezifikation?
Wenn es für die Geschäftsseite nicht mehr lesbar ist. Ein Szenario, das als „given-when-when-when-then-then-when-when“ verkettet ist, kann von niemandem validiert werden, und wenn sich zehn Leute zusammensetzen müssen, um seine Bedeutung zu entschlüsseln, hat es seinen Zweck verfehlt. Die Struktur für gewöhnliche Testfälle wiederzuverwenden ist in Ordnung, aber speichere sie in einem separaten Ordner oder kennzeichne sie mit einem Tag.
