Behavior Driven Development (BDD) ist eine Methode, bei der Anforderungsspezialisten, Entwickler und Tester gemeinsam Testfälle in einer für alle lesbaren Syntax formulieren, typischerweise Gherkin. Der Kern ist eine einheitliche Sprache über den gesamten Projektzyklus. BDD scheitert in der Praxis oft daran, dass Teams Testfälle erst nachträglich in Gherkin schreiben, statt die Methode von Anfang an als Kommunikationswerkzeug zu nutzen.
Das Wichtigste in Kürze
- Gherkin-Syntax allein ist noch kein BDD: Wer Testfälle erst nach der Entwicklung in Gherkin übersetzt, verliert den einzigen echten Vorteil, nämlich die gemeinsame Sprache von Anforderung bis Test.
- BDD-Szenarien sollten ein einziges Verhalten beschreiben und als Richtwert fünf bis sieben Schritte umfassen, damit sie auch nach Monaten noch lesbar und wartbar bleiben.
- Den Akzeptanztest komplett mit BDD abzudecken erzeugt technische Schulden: Lange UI-Schrittfolgen in Gherkin zu pressen macht Testfälle unverständlicher, nicht verständlicher.
- Jedes Feature-File ist Code und muss wie Code gepflegt werden; wer das unterschätzt, holt sich eine zusätzliche Abstraktionsschicht ins Projekt, ohne den Kommunikationsnutzen zu realisieren.
Was Behavior Driven Development eigentlich bedeutet
Behavior Driven Development, kurz BDD, ist ein Vorgehen, bei dem das gesamte Team Anforderungen so formuliert, dass sie direkt im Test verwendbar sind. Die Idee stammt aus den Jahren um 2006 und ist damit kein neuer Trend, auch wenn sie oft so wirkt.
Der Kern ist ein Zyklus, ähnlich dem Test-Driven-Ansatz, der bei der Anforderung beginnt. Anforderungsspezialisten, Entwickler, Tester und die Kollegen aus der Testinfrastruktur arbeiten an einem gemeinsamen Vokabular und schreiben damit Testfälle in einer Syntax, die jeder lesen kann. Üblich ist das Gherkin-Format, es geht aber auch anders.
Diese Testfälle werden dann im Sprint oder im jeweiligen Entwicklungsprozess abgearbeitet. Parallel kann die Testautomatisierung starten. Am Ende stehen idealerweise viele grüne Tests, und das Team hat von der Anforderung bis zum Test denselben Kenntnisstand und dieselbe Sprache.
Der eigentliche Gewinn ist die gemeinsame Sprache
Der größte Vorteil von BDD ist eine einheitliche Sprache über den ganzen Projektzyklus hinweg. Andreas Döring, Testautomatisierer und Verfechter der Methode, sieht genau darin den Kern.
Ohne diese gemeinsame Basis passiert das übliche Auseinanderlaufen: Das Business fordert etwas, die Entwicklung implementiert eine leicht andere Lesart, einzelne Sonderfälle werden anders verstanden. Die Tester kommen am Ende der Kette an und müssen die Differenzen zusammenpacken, die längst entstanden sind.
BDD ist eigentlich ein sehr naheliegendes, sehr schönes Vorgehen. Ich sehe nur manchmal ein paar Praktiken, die mir schwerfallen zu glauben, dass sie gut sind. Andreas Döring
Projekte scheitern fast immer an Kommunikation, nicht an Technik. Genau hier setzt BDD an, indem es den Abstimmungsprozess an den Anfang zieht und das gemeinsame Verständnis erzwingt, bevor Code entsteht.
Warum BDD am Ende des Prozesses keinen Sinn ergibt
Wer seine Testfälle erst ganz am Schluss in Gherkin schreibt, hat kein BDD gemacht, sondern nur Testfälle in einer anderen Notation. Genau das ist die häufigste Fehlanwendung: Anforderungen entstehen in irgendeinem Tool, es wird entwickelt, und die QA setzt sich am Ende hin, um noch einmal Anforderungen zu schreiben.
Damit geht der eigentliche Nutzen verloren. Die gemeinsame Sprache lässt sich nicht nachträglich in einen Prozess einschmuggeln, der ohne sie gelaufen ist. Der Entwickler hat zu diesem Zeitpunkt nichts mehr davon, das Kind ist in den Brunnen gefallen.
Gegen Gherkin als reines Testfall-Format spricht nichts, wenn es dem Tester hilft. Problematisch wird es, wenn man sich eine zusätzliche Abstraktionsschicht in die Automatisierung holt, die nur für einen selbst existiert. APIs, User Interface und Infrastruktur muss man ohnehin ansprechen. Eine Schicht obendrauf, die niemand sonst nutzt, kostet Aufwand ohne Gegenwert.
Jeder Gherkin-Schritt ist Code, der gepflegt werden will
BDD sieht einfach aus, und genau das ist die Falle. Eine lesbare Syntax verführt das Management zu der Ansage, das mal eben einzuführen, weil es so unkompliziert wirkt. Nur: was einfach aussieht, ist deshalb nicht einfach.
Jedes Feature-File ist Code, vergleichbar mit einer Java-Klasse, und muss genauso sorgfältig behandelt werden. Die Kunst steckt in den Details: Wie schreibst du die Feature-Files, mit welcher Syntax, mit welchen Parametern, wo legst du die Testdaten ab? Das ist zunächst Mehraufwand, und dieser Aufwand gehört von Anfang an in die Projektplanung.
Andreas zieht den Vergleich zum Scrum-Manifest. Die Lektüre umfasst wenige Seiten, die Reife im Team dauert Jahre. Zwischen der Einfachheit der Darstellung und der Einfachheit der Umsetzung gibt es keine Korrelation.
Ein Szenario beschreibt genau ein Verhalten
Ein gutes Szenario beschreibt ein einziges Verhalten, nicht einen kompletten Ablauf. Wie viele Szenarien zu einer User Story gehören, schwankt: Im besten Fall ist es ein 1-zu-1-Matching, bei vielen Sonderfällen werden es drei, vier, fünf oder mehr.
Als Richtwert für die Länge nennt Andreas fünf bis sieben Schritte pro Testfall. Ein Standard, der das vorschreibt, existiert nicht. Als Orientierung dienen zwei Prinzipien aus dem Clean Code: “don’t repeat yourself” und “keep it simple, stupid”.
Lange Konstrukte mit gestapelten When- und Then-Schritten über zehn oder fünfzehn Zeilen sind ein Warnsignal. Wenn ein Testfall eine ganze A4-Seite füllt, ist er weder nachvollziehbar noch macht er ein halbes Jahr später noch Freude. Solche Fälle entstehen, wenn man BDD nur um BDD willen betreibt.
Der bessere Weg führt über das Zerlegen großer Prozesse in kleine Schritte. Ein Dokument aufnehmen und ablegen ist ein Schritt. Für diesen Schritt lässt sich sauber durchdenken, welche Sonderfälle es gibt. Arbeitet man sich so durch den Prozess, hat man am Ende jeden Teil abgedeckt, ohne den gesamten Durchlauf am Stück durchtesten zu müssen.
Beschreibe Verhalten, nicht Bedienelemente
Testfälle sollten auf der Verhaltensebene bleiben und nicht die konkrete Oberfläche abbilden. Anweisungen wie “öffne das Dropdown” oder “gib in die Eingabezeile” gehören nicht in ein Feature-File, weil sich solche Details ständig ändern.
Wer die UI bis ins Bedienelement spezifiziert, schreibt seine Feature-Files jedes Mal um, sobald sich ein Dropdown ändert oder ein Eingabefeld dazukommt. Kein Business-Analyst hat Freude daran, die Oberfläche in diesem Detailgrad zu pflegen.
Die richtige Abstraktionsebene fragt: Was passiert im System? Welche Zustände müssen durchlaufen werden, welche Randbedingungen gelten, was ist aus juristischer Sicht zu beachten? Diese Ebene reicht völlig aus und bleibt stabil, während sich die Oberfläche weiterentwickelt.
Die Klarheit entsteht vor der Automatisierung
Der größte Wert von BDD entsteht auf dem Weg zur Syntax, nicht erst beim grünen Test. Eine Anforderung in Gherkin zu formulieren, zwingt Anforderer, Tester und Entwickler dazu, gemeinsam zu durchdenken, was die Anforderung eigentlich erreichen soll und wie sie funktioniert.
Ein Feature-File ist in gewissem Sinn ein Modell, das aus dem Prosa-Text oder der ursprünglichen Idee entsteht. Der Spaß und der Erkenntnisgewinn liegen im Erstellen dieses Modells. Die Testautomatisierung dahinter ist dann ein zusätzlicher Nutzen, kein Selbstzweck.
Daraus folgt eine klare Reihenfolge. Wenn das Anforderungsmanagement im Team schon funktioniert und alle miteinander reden, lohnt sich der Schritt zur gemeinsamen Sprache. Fehlt diese Kommunikation, ist sie das erste Problem, das gelöst werden muss, lange bevor man über Syntax spricht. Sonst formalisiert man nur die eigene Freitext-Anforderung und gewinnt nichts.
Wie du BDD im Projekt einführst, ohne dich zu verheben
Fang klein an und nicht mit dem großen Akzeptanztest. Such dir einen überschaubaren Baustein, gern im Backend statt im Frontend, und sammle dort Erfahrung in deinem konkreten Umfeld.
Tutorials helfen nur begrenzt. Sie bringen dir die Syntax bei, beantworten aber nicht die Frage, wie BDD bei dir funktioniert. Ein kleiner Proof of Concept im eigenen Kontext zeigt schneller, mit welchen Schnittstellen und Tools du arbeitest und welchen Aufwand du dir wirklich einhandelst.
Voraussetzung ist ein funktionierendes Team, in dem auch der Product Owner oder die Business-Analysten mitspielen. Nimm dir zu Sprint-Beginn bewusst Zeit, eine Anforderung in der gewählten Syntax auszuformulieren. Funktioniert es in einer Komponente, kannst du es ausweiten und auch übergreifende Themen angehen, etwa Frontend und Backend im Integrationstest verheiraten.
Beim Format gibt es Spielraum. Neben dem klassischen Given-When-Then-Schema nennt Andreas das Tool Gauge, bei dem Tests in Markdown geschrieben werden. Das ist freier als Gherkin, verfolgt aber dasselbe Ziel: etwas zu schreiben, das für alle lesbar ist.
Die Toolchain ist sekundär, die Anbindung der Fachseite nicht
Bei den Werkzeugen gibt es kein eindeutig bestes Framework, fast alle funktionieren. Genannt werden Cucumber, das Serenity-Framework, JBehave und Gauge. Welches du wählst, ist weniger wichtig als die Frage, wie es sich in deine bestehende Automatisierung einfügt.
Wichtig ist die Einordnung: BDD-Werkzeuge sind immer nur eine Schicht über dem eigentlichen Toolstack. Selenium, API-Tools und die übrige Infrastruktur brauchst und pflegst du weiterhin. Das BDD-Framework ersetzt nichts davon, es kommt obendrauf.
Die größere Herausforderung liegt in der Anbindung der Fachseite. Anforderungen entstehen oft in Tools wie Jira. Plugins wie X-Ray verbinden solche Tools mit Gherkin, sodass sich die Feature-Files exportieren und in die Pipeline übernehmen lassen.
Dabei lohnt sich Rücksicht auf die Beteiligten. Entwickler und Automatisierer kommen mit ihren IDEs und Plugins in IntelliJ oder Visual Studio Code problemlos zurecht. Ein Fachbereich, der Weboberflächen gewohnt ist, gerät dagegen in Schockstarre, wenn er plötzlich Feature-Files in einer Entwicklungsumgebung pflegen soll. Wer mit Weboberflächen und Jira arbeitet, fährt mit einer Lösung wie X-Ray besser, weil sie die Fachseite dort abholt, wo sie ohnehin arbeitet.
BDD ist kein Allheilmittel
BDD bringt viele Vorteile, ist aber kein Werkzeug, das Probleme von allein löst. Die zentrale Botschaft: Was einfach aussieht, muss trotzdem gepflegt werden, und im schlechtesten Fall holt man sich mit BDD eine zusätzliche Quelle technischer Schulden ins Projekt.
Wer das bewusst angeht, klein startet und die gemeinsame Sprache wirklich vor die Entwicklung zieht, gewinnt eine starke Methode. Wer Gherkin am Ende des Prozesses als Pflichtübung anhängt oder alles mit dem Holzhammer in Given-When-Then presst, baut sich Aufwand ohne Nutzen auf.
