Definition
Erweiterung von TDD um eine fachliche Sicht. Tests werden in einer natürlichsprachlichen Notation („Given-When-Then") formuliert, die auch von Domain-Experten verstanden wird. Beliebte Frameworks: Cucumber, SpecFlow, JBehave. Brücke zwischen Anforderungs-Management und Software-Test. Verbessert die Akzeptanztest-Coverage und erleichtert Stakeholder-Reviews.
In der Praxis
BDD scheitert fast nie an der Syntax, sondern an der falschen Autorenschaft: Die Gherkin-Szenarien schreibt der Entwickler allein am Rechner — dann ist es nur TDD mit zusätzlichem Übersetzungsaufwand, und der eigentliche Wert verpufft. Der Kern der Methode ist das Gespräch: Fachlichkeit, Test und Entwicklung formulieren die Akzeptanzkriterien gemeinsam, bevor gebaut wird. Genau dort werden die teuren Missverständnisse entdeckt — nicht im Abnahmetest drei Monate später. Zweites Fehlerbild: Szenario-Inflation. Tausende automatisierte Szenarien, die niemand mehr liest, sind kein Sicherheitsnetz, sondern Wartungslast; BDD lebt von wenigen, repräsentativen Beispielen je Verhalten. Drittens die Verwechslung mit dem Anforderungsmanagement: Szenarien präzisieren Anforderungen, sie ersetzen sie nicht — die Rückverfolgbarkeit von der Anforderung zum Szenario muss herstellbar bleiben, sonst wird es im regulierten Audit eng. Richtig eingesetzt, ist BDD die beste Brücke zwischen Fachabteilung und Team, die ich kenne — und die Akzeptanztests dokumentieren sich fast nebenbei.
Häufige Fragen zu BDD
Worin unterscheidet sich BDD von TDD — brauchen wir beides?
Beide arbeiten test-first, aber auf verschiedenen Ebenen und mit verschiedenen Zielgruppen. TDD steuert die technische Ebene: Der Entwickler schreibt Unit-Tests für Module und Funktionen, in der Programmiersprache, für sich und das Team — Ziel ist korrekter, sauber strukturierter Code. BDD steuert die fachliche Ebene: Verhaltensweisen des Systems werden in natürlicher Sprache nach dem Muster „Given-When-Then" beschrieben, verständlich für Fachabteilung, Test und Entwicklung — Ziel ist ein gemeinsames Verständnis des geforderten Verhaltens, bevor es gebaut wird. Die Zuordnung: BDD klärt, was das System tun soll, TDD sichert, wie es innen funktioniert. Ob Sie beides brauchen, hängt vom Umfeld ab: Bei fachlich komplexen Anforderungen mit vielen Stakeholdern lohnt BDD, bei technisch geprägten Komponenten reicht oft TDD. Beides zusammen ist kein Widerspruch, sondern die sauberste Testpyramide.
Taugen BDD-Szenarien als Verifizierungsnachweise im Sinne der ISO/IEC/IEEE 29119?
Teilweise — und die Grenze zu kennen ist wichtig. Die Normenreihe ISO/IEC/IEEE 29119 beschreibt Software-Testprozesse, -dokumentation und -techniken modellneutral: Sie fordert eine risikobasierte Testplanung, definierte Testbedingungen, dokumentierte Ergebnisse und einen Abschlussbericht. BDD-Szenarien können darin die Rolle spezifizierter Akzeptanztestfälle übernehmen, und ihre automatisierte Ausführung liefert reproduzierbare Ergebnisse. Was BDD allein nicht liefert: die Teststrategie, die Auswahl der Testtechniken nach Risiko, die Abdeckung der nicht-funktionalen Anforderungen und die formale Abschlussbewertung. Wer BDD in einen Testprozess nach 29119 einbettet, hat eine starke Kombination — die Szenarien als lebendige Spezifikation, der Prozessrahmen als Audit-Nachweis. Wer BDD als komplettes Testkonzept verkauft, scheitert an der ersten Systemtest-Frage (ISO/IEC/IEEE 29119).
Wie starten wir mit BDD, ohne in der Szenario-Flut zu ertrinken?
Beginnen Sie mit dem Format „Three Amigos": Zu jeder neuen Anforderung setzen sich Fachlichkeit, Entwicklung und Test für dreißig Minuten zusammen und formulieren die Akzeptanzkriterien als Beispiele — das Gespräch ist der Wert, die Szenarien sind sein Protokoll. Zweitens die Disziplin der Auswahl: Pro Verhalten zwei bis fünf repräsentative Szenarien, die die Regel und ihre wichtigsten Ausnahmen zeigen — keine erschöpfende Datenwühlerei, die gehört in tiefere Teststufen. Drittens die Sprache: Formulieren Sie im Vokabular der Fachdomäne, nicht in Entwickler-Jargon; wenn die Fachseite die Szenarien nicht ohne Dolmetscher lesen kann, ist das Ziel verfehlt. Viertens die Automatisierung erst nach Stabilisierung der Sprache — sonst pflegen Sie doppelt. Und fünftens: Szenarien sind Wegwerf-Dokumentation mit Halbwertszeit; veraltete Szenarien werden gelöscht, nicht konserviert.