BDD: Von den Best Practices bis hin zu ihren Abweichungen

Geschrieben von Gilles Ménède | Jul 16, 2026 7:55:44 AM

BDD (Behaviour Driven Development) ist eine Methode, die 2003 von Dan North bekannt gemacht wurde und sich aus TDD (Test Driven Development) ableitet, das sie ergänzt.

Warum BDD einsetzen? Gerade um die häufigen Probleme mit Spezifikationen im agilen Entwicklungsansatz anzugehen:

  • Keine formale Erläuterung des Kontexts,
  • Spezifikationen, die von verschiedenen Rollen oder Akteuren unterschiedlich interpretiert werden können,
  • Nicht unbedingt auf dem neuesten Stand.

BDD ist daher eine agile Methode, die darauf abzielt, die verschiedenen an der Entwicklung einer Funktion beteiligten Akteure hinsichtlich der beabsichtigten Funktionsweise aufeinander abzustimmen. Das Ziel von BDD ist es, Abnahmetests zu entwerfen, die das Verhalten der Funktion veranschaulichen, wobei Methoden wie die „3 Amigos“ oder das Beispiel-Mapping zum Einsatz kommen. Der BDD-Ansatz wird in der Regel in drei Phasen durchgeführt: Entdeckung, Formulierung und Automatisierung.

Die richtige Anwendung

Die Beteiligten werden mithilfe gemeinsam entworfener Beispiele aufeinander abgestimmt, die das Verhalten der Funktionalität veranschaulichen: Dies ist die „Discovery“-Phase, die häufig durch das Treffen der „3 Amigos“ (Kunde, Entwickler und Tester) erreicht wird. Dieses Treffen sorgt für ein gemeinsames Verständnis der Anforderung und ermöglicht das Verfassen von Abnahmeszenarien zur Validierung der Abnahmekriterien.

Diese Beispiele werden in einer gemeinsamen Sprache, Gherkin, formuliert, die von den verschiedenen Rollen der „3 Amigos“ leicht verstanden wird. Die Gherkin-Sprache ist so konzipiert, dass strukturierte Tests in natürlicher Sprache geschrieben werden können, die a priori für alle verständlich ist. Gherkin-Tests werden mit den vier Grundelementen geschrieben: GIVEN / WHEN / THEN … AND (GIVEN ein bestimmter Kontext, WHEN ich führe eine Aktion aus, THEN erhalte ich ein Ergebnis1 AND ein Ergebnis2).

Ausgehend von dieser strukturierten (und formatierten) Formulierung des Verhaltens der Funktionalität ist es möglich, diese Beispiele in ein Software-Tool wie beispielsweise Cucumber zu integrieren, das diese Gherkin-Sprache interpretiert, um automatisierte Abnahmetests auszuführen, die an diese Beispiele angepasst sind. Dies ist die Automatisierungsphase.

Ihre Abweichungen

BDD wird mittlerweile in vielen Unternehmen eingesetzt, um das Verhalten bestimmter Funktionen in enger Zusammenarbeit mit den Anwendern zu testen. Doch auch wenn BDD dazu dient, ein gemeinsames Verständnis der Anforderungen zu erreichen, gibt es nach wie vor eine Reihe von Missverständnissen rund um diese agile Praxis, die zu gewissen Missbräuchen führen können. Welche sind das?

BDD wird ausschließlich als Automatisierung betrachtet

  • In diesem Fall geht der wesentliche Beitrag von BDD verloren: die Möglichkeit, dass alle das gleiche Verständnis davon haben, was erwartet wird.

Szenarien werden ausschließlich vom Product Owner oder vom Tester verfasst und entworfen.

  • In diesem Fall gibt es zwar Beispiele. Leider ist deren Qualität oft unzureichend, da sie nicht von verschiedenen Rollen überprüft wurden.

Versäumnis, Abnahmeszenarien zu verfassen

  • Manchmal finden Synchronisationsbesprechungen statt, doch am Ende entsteht kein Szenario. Dies ist insofern problematisch, als ein Großteil der Informationen verloren geht, weil sie in Vergessenheit geraten. Außerdem zwingt es mehr Personen zur Teilnahme an diesen Besprechungen, was einen höheren Aufwand erfordert.

Tests, die nicht für alle Zielgruppen verständlich sind

  • Ein BDD-Test muss von jedem im Team (und manchmal auch darüber hinaus) verstanden werden. Das Schreiben von Tests, die nicht von allen verstanden werden, gewährleistet nicht, dass alle dasselbe verstehen. Im Allgemeinen ermöglicht es dem Geschäft auch nicht, wirklich zu validieren, was entwickelt werden soll.

Die BDD wird während des Sprints erstellt

  • „Während eines Sprints“ bedeutet nicht „während der Entwicklung“. Doch selbst wenn die BDD vor der Entwicklung durchgeführt wird, hat dieser Prozess Auswirkungen auf das Team, das sich zur Umsetzung eines US verpflichten musste, den es möglicherweise nicht vollständig verstanden hat.

Einsatz von Gherkin als BDD

  • Gherkin ist eine Sprache. BDD kann auch andere Formen annehmen … genauso wie es möglich ist, Tests in Gherkin auszuführen, die kein BDD sind (z. B.: Das Karaté-Tool bietet Tests in Gherkin an, die von funktionalen Profilen nicht verstanden werden können).

Vor dem Sprint besteht die BDD-Praxis darin, durch Discovery ein gemeinsames Verständnis der Anforderung bei allen beteiligten Akteuren zu validieren. Dieses Verständnis wird durch Beispiele, Akzeptanzkriterien und Akzeptanzszenarien formuliert, die anschließend in einem Tool für den Entwurf und die Ausführung automatisierter Tests implementiert werden.


Die Anwendung der verschiedenen Phasen dieses Ansatzes trägt dazu bei, BDD-Drift entgegenzuwirken und vor allem die derzeitige Verwirrung hinsichtlich der verschiedenen Begriffe rund um das BDD-Konzept zu beseitigen.
Vollständigen Beitrag anzeigen