Behavior Driven Development ist ein gemeinsamer Entwicklungsprozess, der gewünschtes Softwareverhalten vor der Umsetzung durch konkrete Beispiele klärt. Fachseite, Entwicklung und Test besprechen Regeln, Randfälle und beobachtbare Ergebnisse, bevor Code entsteht. Cucumber beschreibt dafür seit 2026 die drei Praktiken Discovery, Formulation und Automation (Cucumber, 2026). BDD Testing setzt die vereinbarten Beispiele als prüfbare Spezifikationen um. Gherkin und Cucumber können diese Arbeit stützen, definieren BDD jedoch nicht. Dieser Leitfaden zeigt Prozess, Rollen, Testebenen, Evidenz und einen begrenzten Einstieg mit einer einzelnen Story.

Kurz gefasst: BDD verbindet Fachseite, Entwicklung und Test durch konkrete Beispiele vor der Umsetzung. Discovery klärt Regeln, Formulation hält ausgewählte Beispiele lesbar fest, Automation prüft sie ausführbar. Eine Studie ordnete 166 BDD-Fachbeiträge ein, fand aber wenig Industrieevidenz und wenige Messgrössen (Binamungu und Maro, 2023).

Abbildung 1: Discovery, Formulation und Automation bilden eine BDD-Arbeitsschleife mit Feedback.

Was ist Behavior Driven Development?

Behavior Driven Development ist ein kollaborativer Softwareentwicklungsprozess mit Beispielen für beobachtbares Verhalten. Die heute verbreitete Prozessbeschreibung umfasst 3 Praktiken: Discovery, Formulation und Automation (Cucumber, 2026). BDD verbindet damit Anforderungsklärung, lesbare Spezifikation und testgetriebene Umsetzung in kurzen Arbeitszyklen.

Die Beteiligten sprechen über eine kleine bevorstehende Änderung. Sie sammeln konkrete Situationen, erwartete Ergebnisse und offene Fragen. Aus der Unterhaltung entsteht eine gemeinsame Beschreibung des gewünschten Verhaltens. Ausgewählte Beispiele werden später ausführbar. Der Prozess beginnt damit vor dem Programmieren und bleibt während der Umsetzung prüfbar.

Der Begriff entstand aus Dan Norths Arbeit mit Test Driven Development. North startete JBehave Ende 2003 und veröffentlichte seine BDD-Beschreibung 2006 (Dan North, 2006). Die Agile Alliance ordnet BDD als Verbindung und Weiterentwicklung von TDD- und ATDD-Praktiken ein (Agile Alliance, 2015). Der Vergleich von BDD und TDD erklärt die verschiedenen Arbeitsebenen.

BDD ist ein Prozess. BDD Testing ist die Prüfpraxis rund um vereinbarte Beispiele. Gherkin ist eine strukturierte Textnotation. Cucumber liest Gherkin und verbindet Schritte mit Programmcode. Diese Begriffe beantworten verschiedene Fragen:

Die Agile Alliance beschreibt BDD als unabhängig von einem bestimmten Werkzeug oder einer bestimmten Programmiersprache (Agile Alliance, 2015). Ein Team kann Beispiele auf Karten, in einer Tabelle oder direkt im Testcode formulieren. Entscheidend bleibt die gemeinsame Arbeit vor der Umsetzung.

Welches Problem löst BDD?

Abbildung 2: Fachseite, Entwicklung und Test klären gemeinsam ein konkretes Beispiel.

BDD macht Mehrdeutigkeit sichtbar, bevor sie in Code und Tests eingeht. Eine systematische Studie ordnete 166 Veröffentlichungen aus den Jahren 2006 bis 2021 ein und fand zugleich wenig Industrieevaluationen (Binamungu und Maro, 2023). Der belegbare Nutzen liegt deshalb zuerst in der strukturierten Klärung.

User Stories nennen oft ein Ziel, lassen Geschäftsregeln aber offen. „Kunden können eine Bestellung stornieren“ sagt noch nichts über Fristen, Teilbestellungen, Zahlstatus oder Rückerstattungen. Entwicklung und Test können dieselben Wörter unterschiedlich lesen. Diese Unterschiede fallen häufig erst bei der Abnahme auf, wenn bereits mehrere technische Entscheidungen davon abhängen.

Konkrete Beispiele zwingen das Team zu überprüfbaren Aussagen. Ein Beispiel nennt einen Ausgangszustand, ein Ereignis und ein sichtbares Resultat. Die Beteiligten erkennen damit fehlende Regeln und widersprüchliche Annahmen. Offene Fragen bleiben ausdrücklich offen, statt unbemerkt in eine Implementierung zu rutschen.

BDD ersetzt keine Produktentscheidung. Ein Workshop kann zeigen, dass die Stornierungsfrist ungeklärt ist. Er kann die Frist nicht fachlich festlegen. Gleiches gilt für Risiko, Datenschutz, Performance, Barrierefreiheit und explorative Prüfung. Der Leitfaden zu BDD Testing zeigt, wie vereinbarte Beispiele in eine breitere Teststrategie gehören.

In einer BDD-Arbeitsschleife dienen Beispiele mehreren Gruppen. Die Fachseite erkennt die beabsichtigte Wirkung. Entwicklerinnen sehen notwendige Zustände und Schnittstellen. Testende prüfen Randfälle und Beobachtbarkeit. Die Spezifikation wird brauchbar, wenn alle Beteiligten denselben Fall prüfen und auf dasselbe erwartete Ergebnis kommen.

Wie funktionieren Discovery, Formulation und Automation?

Discovery, Formulation und Automation bilden eine wiederholte 3-Phasen-Schleife für kleine Änderungen (Cucumber, 2026). Discovery sammelt Regeln und Beispiele, Formulation hält ausgewählte Fälle lesbar fest, Automation verbindet jeden Fall mit einer ausführbaren Prüfung. Neue Erkenntnisse führen zurück zur nächsten Discovery-Unterhaltung.

Der Ablauf für eine einzelne Regel sieht so aus:

1. Die Fachseite beschreibt eine kleine bevorstehende Änderung.

2. Die drei Perspektiven sammeln positive, negative und begrenzende Beispiele.

3. Das Team wählt die Fälle aus, die eine Regel am klarsten erklären.

4. Es formuliert jeden Fall mit Ausgangslage, Ereignis und beobachtbarem Resultat.

5. Die Entwicklung verbindet den ersten Fall mit einer ausführbaren Prüfung.

6. Der Test schlägt vor der Umsetzung fehl, danach implementiert das Team das Verhalten.

7. Der bestandene Test bleibt bei der Spezifikation und läuft bei Änderungen erneut.

Cucumber fasst die Benennung so zusammen: „We call these practices Discovery, Formulation, and Automation“ (Cucumber, 2026). Die Reihenfolge trennt BDD von nachträglich formulierter Testautomatisierung. Ein nach dem Code geschriebenes Given-When-Then-Szenario kann ein sinnvoller Regressionstest sein. Der Arbeitsablauf erfüllt jedoch nicht die aktuelle Cucumber-Definition von BDD (Cucumber Myths, 2026).

Formulation kann Gherkin-Syntax nutzen. Lesbarkeit verlangt mehr als Schlüsselwörter. Ein Szenario sollte genau eine Regel erklären, technische Selektoren auslassen und ein Resultat nennen, das ein Benutzer oder externes System erkennen kann.

Wer arbeitet in einer Three-Amigos-Session zusammen?

Eine Three-Amigos-Session braucht mindestens 3 Perspektiven: Geschäft oder Produkt, Entwicklung und Test (Cucumber, 2026). Der Name begrenzt die Teilnehmerzahl nicht. Cucumber nennt 3 bis 6 Personen als praktische Faustregel und 25 bis 30 Minuten als Richtwert pro Story (Cucumber, 2026).

Die Produktperspektive erklärt Ziel, Umfang und Geschäftsregeln. Die Entwicklung nennt technische Abhängigkeiten, Datenzustände und Umsetzungsgrenzen. Die Testperspektive fragt nach negativen Pfaden, Grenzwerten und sichtbaren Ergebnissen. Weitere Fachpersonen können teilnehmen, wenn Recht, Betrieb, Sicherheit oder Datenverantwortung für die Story relevant sind.

Example Mapping gibt der Unterhaltung eine einfache Ordnung. Cucumber verwendet eine gelbe Karte für die Story, blaue Karten für Regeln, grüne Karten für Beispiele und rote Karten für offene Fragen (Cucumber, 2026). Die Farben sind optional. Die Trennung der Information ist der nützliche Teil.

Beispiel für eine Stornierungsstory:

• Story: Kundinnen können eine bezahlte Bestellung stornieren.

• Regel: Eine Stornierung ist bis zum Versand möglich.

• Beispiel: Bezahlt und noch nicht versandt führt zu einer Rückerstattung.

• Gegenbeispiel: Bereits versandt führt zu einer verständlichen Ablehnung.

• Offene Frage: Gelten für digitale Produkte andere Fristen?

Eine breite Karte zeigt fehlenden Zuschnitt. Zu viele Regeln oder lange Szenarien sprechen für mehrere Stories. Offene rote Karten verhindern erfundene Antworten. Das Team beendet die Unterhaltung mit geklärtem Umfang oder einer klar benannten Entscheidung, die vor der Umsetzung noch fehlt.

Wie führt ein Team BDD mit einer Story ein?

Abbildung 3: Example Mapping ordnet Story, Regeln, Beispiele und offene Fragen.

Ein begrenzter Pilot mit 1 kleinen, kommenden Story liefert die sauberste Einführung. Cucumber empfiehlt Discovery so spät wie sinnvoll vor der Umsetzung und nennt 25 bis 30 Minuten als Orientierungswert (Cucumber, 2026). Der Pilot prüft die Arbeitsweise, ohne einen organisationsweiten Umbau zu verlangen.

1. Story wählen: Nehmen Sie eine fachlich relevante Änderung mit überschaubarem Umfang und einem beobachtbaren Resultat.

2. Perspektiven einladen: Produkt, Entwicklung und Test müssen vertreten sein. Ergänzen Sie Fachrollen bei konkretem Bedarf.

3. Regeln sammeln: Schreiben Sie jede Geschäftsregel getrennt auf. Markieren Sie unklare Begriffe sofort.

4. Beispiele prüfen: Ergänzen Sie Normalfälle, Grenzwerte, Ablehnungen und fehlende Daten.

5. Fragen sichern: Lassen Sie ungeklärte Punkte offen und benennen Sie die entscheidende Person.

6. Szenarien formulieren: Wählen Sie wenige aussagekräftige Beispiele und beschreiben Sie sichtbare Resultate.

7. Testebene wählen: Prüfen Sie jede Regel auf der kleinsten sinnvollen Ebene.

8. Vor dem Code ausführen: Lassen Sie den ersten Test scheitern, implementieren Sie das Verhalten und führen Sie ihn erneut aus.

9. Nachbesprechen: Prüfen Sie Verständlichkeit, Diagnosezeit und Pflegeaufwand nach der Story.

Der Pilot braucht klare Beobachtungskriterien. Das Team kann festhalten, wie viele offene Fachfragen vor dem Code geklärt wurden, welche Szenarien später umgeschrieben werden mussten und wie schnell ein fehlgeschlagener Test erklärt werden konnte. Diese Werte beschreiben den eigenen Prozess. Sie sind keine allgemeine BDD-Wirkungskennzahl.

Eine einzelne erfolgreiche Story rechtfertigt noch keine Vorgabe für alle Teams. Wiederholen Sie den Ablauf mit verschiedenen Risikotypen. Streichen Sie Schritte, die keinen Beitrag zur Klärung oder Prüfung leisten. Behalten Sie das gemeinsame Gespräch als festen Kern.

Welche Rollen spielen Gherkin und Cucumber?

Gherkin ist eine strukturierte Textnotation mit mehr als 70 Sprachvarianten; Cucumber ist ein Werkzeug, das diese Texte liest und über Step Definitions mit Code verbindet (Cucumber Gherkin Reference, 2026). Beide können BDD stützen. Der Prozess bleibt von einer bestimmten Notation oder Programmiersprache unabhängig.

Gherkin ordnet eine Spezifikation mit Schlüsselwörtern wie Feature, Rule, Scenario, Given, When und Then. Given beschreibt den Ausgangskontext. When nennt ein Ereignis oder eine Aktion. Then nennt ein Ergebnis, das ein Benutzer oder externes System beobachten kann. Cucumber empfiehlt 3 bis 5 Schritte pro Beispiel als Lesbarkeitsrichtwert, nicht als Syntaxgrenze (Cucumber Gherkin Reference, 2026).

Cucumber liest jedes Szenario und sucht passende Step Definitions. Diese Funktionen führen den technischen Teil aus, etwa einen API-Aufruf oder eine Browseraktion. Das Werkzeug berichtet Erfolg oder Fehler pro Szenario. Der Cucumber-Testing-Leitfaden behandelt Projektstruktur, Step Definitions und Pflege genauer.

Eine `.feature`-Datei belegt nur, dass strukturierter Text existiert. BDD verlangt nach aktueller Cucumber-Dokumentation zuerst Discovery, dann Formulation und Automation (Cucumber Myths, 2026). Teams sollten daher getrennt prüfen, ob Fachpersonen beteiligt waren, Beispiele vor dem Code entstanden und Szenarien weiterhin verständlich sind.

Auf welchen Testebenen lassen sich BDD-Beispiele prüfen?

BDD-Beispiele können auf Komponenten-, Service-, Integrations- oder UI-Ebene laufen. Der ISTQB-Lehrplan von 2024 beschreibt eine Testpyramide mit vielen kleinen, schnellen Prüfungen unten und weniger langsamen Systemprüfungen oben (ISTQB, 2024). Die passende Ebene beweist Verhalten mit möglichst wenig unnötigem Systemumfang.

Eine Rabattregel lässt sich meist direkt in der Domänenlogik prüfen. Eine Preisabfrage zwischen Diensten passt auf die API- oder Integrationsebene. Ein kritischer Kaufabschluss braucht wenige UI-Systemprüfungen. Diese Verteilung folgt der Testpyramide und reduziert doppelte, breite Prüfungen.

BDD legt die Teststrategie nicht vollständig fest. Sicherheitsprüfungen, Lasttests, Barrierefreiheit und exploratives Testen brauchen eigene Ziele. Eine ausführbare Spezifikation deckt das vereinbarte Verhalten ab. Unbekannte Risiken bleiben Gegenstand weiterer Testarbeit. Für verteilte Systeme hilft der separate Leitfaden zur API-Testautomatisierung.

Was belegen aktuelle Studien und wo liegen Grenzen?

Abbildung 4: 166 kartierte BDD-Fachbeiträge stehen wenig Industrieevidenz und wenigen Messgrössen gegenüber.

Die stärkste Übersicht ordnete 166 BDD-Fachbeiträge aus 2006 bis 2021 ein und meldete wenig Industrieevidenz sowie wenige Messgrössen (Binamungu und Maro, 2023). BDD hat damit eine breite Forschungsspur, aber keine belastbare universelle Prozentzahl für weniger Defekte, kürzere Lieferzeit oder höheren ROI.

„The study identified 166 papers which were mapped.“ (Binamungu und Maro, 2023)

Die 2025 veröffentlichte Fallstudie untersuchte 4 Teams mit insgesamt 56 Beteiligten über 6 Sprints. Die berichteten Abschlussprozente stammten von 4 Teamleitenden; 50 Prozent sahen die Ziele erfüllt, 50 Prozent teilweise erfüllt (Ribeiro dos Santos et al., 2025). Diese kleine Antwortzahl trägt keine allgemeine Effektgrösse.

Eine begutachtete IEEE-Studie von 2024 prüfte GPT-3.5, GPT-4, Llama-2-13B und PaLM-2 für BDD-Akzeptanztests. Die Resultate gelten für die dort verwendeten Kriterien und Eingaben (Karpurapu et al., 2024). Ein Preprint von 2026 untersuchte 500 Stories aus 4 proprietären Produkten und fand bessere Bewertungen mit Story plus Beschreibung. Die Qualitätswerte schwankten, und Textähnlichkeitsmasse korrelierten meist unter 0,30 mit menschlichen Urteilen (Shahin et al., 2026). Fachliche Prüfung bleibt damit erforderlich.

Wo unterstützt Autemos die Automatisierungsphase?

Autemos kann nach Discovery und Formulation vereinbarte Beschreibungen in ausführbare Testabläufe überführen. Die Produktseite nennt 3 Eingabeformen: Jira-Ticket, User Story und natürlichsprachliche Beschreibung (Autemos, 2026). Die Fachseite bleibt für Regeln und Akzeptanz zuständig; menschliche Prüfung steht vor der Ausführung.

Ein BDD-Team kann eine geklärte Story oder Testbeschreibung als Ausgangspunkt verwenden. Autemos erzeugt daraus visuelle Abläufe, Page Objects und ausführbaren Code, den das Team prüft. Vorhandene Playwright-, Selenium- und Appium-Bestände lassen sich gemäss Produktseite wiederverwenden (Autemos, 2026). Die visuellen Test-Workflows erlauben Fachseite und Entwicklung verschiedene Sichten auf denselben Ablauf.

Die öffentliche Dokumentation nennt keine native Cucumber-Ausführung, keinen Gherkin-Import und keinen `.feature`-Import. Diese Grenze ist relevant für Architekturentscheidungen. Ein bestehendes Cucumber-Projekt braucht eine ausdrücklich geprüfte Integrationsstrategie. Autemos kann die Automatisierungsphase unterstützen, übernimmt jedoch keine Discovery-Unterhaltung und trifft keine fachliche Akzeptanzentscheidung.

Für die Einführung bietet sich ein enger Prüfauftrag an:

• Verwenden Sie eine bereits geklärte Story mit wenigen Beispielen.

• Prüfen Sie erzeugte Schritte fachlich und technisch vor der Ausführung.

• Legen Sie die Testebene je Verhalten bewusst fest.

• Messen Sie Diagnosezeit, Nachbearbeitung und Pflege im eigenen Team.

• Dokumentieren Sie Grenzen zwischen BDD-Spezifikation und Ausführungsplattform.

Häufig gestellte Fragen

Die häufigsten BDD-Fragen betreffen Definition, Werkzeuge und Rollen. Aktuelle Cucumber-Dokumentation trennt den Prozess in 3 Praktiken und nennt mindestens 3 vertretene Perspektiven (Cucumber, 2026). Die folgenden Antworten halten Prozess, Notation, Werkzeug und Evidenz klar auseinander.

Was ist Behavior Driven Development?

Behavior Driven Development ist ein gemeinsamer Entwicklungsprozess, bei dem Fachseite, Entwicklung und Test gewünschtes Verhalten vor der Umsetzung durch konkrete Beispiele klären. Ausgewählte Beispiele werden lesbar formuliert und ausführbar geprüft. Discovery, Formulation und Automation bilden die wiederholte Arbeitsschleife (Cucumber, 2026).

Ist BDD dasselbe wie Cucumber?

BDD und Cucumber sind verschiedene Kategorien. BDD ist der Entwicklungsprozess; Cucumber ist ein Open-Source-Werkzeug, das strukturierte Spezifikationen liest, Step Definitions ausführt und Ergebnisse je Szenario meldet (Cucumber, 2026). Ein Team kann BDD ohne Cucumber betreiben.

Braucht BDD Gherkin und Given-When-Then?

BDD verlangt keine bestimmte Notation oder Programmiersprache (Agile Alliance, 2015). Gherkin mit Given, When und Then ist verbreitet, da es Kontext, Ereignis und beobachtbares Resultat strukturiert. Karten, Tabellen oder andere klare Formate können denselben Formulationszweck erfüllen.

Wer nimmt an einer Three-Amigos-Session teil?

Geschäft oder Produkt, Entwicklung und Test müssen als 3 Perspektiven vertreten sein. Cucumber setzt keine Obergrenze von 3 Personen und nennt 3 bis 6 Teilnehmende als praktische Faustregel (Cucumber, 2026). Weitere Fachrollen kommen bei inhaltlichem Bedarf dazu.

Welche Vorteile von BDD sind wissenschaftlich belegt?

Die Forschung dokumentiert viele BDD-Einsatzfelder, trägt aber keine universelle Effektzahl. Eine Kartierung von 166 Fachbeiträgen fand wenig Industrieevaluationen und einen Mangel an Messgrössen für BDD-Spezifikationen und -Prozesse (Binamungu und Maro, 2023). Teams sollten eigene Ziele und Messwerte definieren.

Fazit

Behavior Driven Development beginnt mit einer kleinen Änderung und konkreten Beispielen vor dem Code. Die aktuelle Prozessbeschreibung hat 3 Praktiken: Discovery, Formulation und Automation (Cucumber, 2026). Geschäft, Entwicklung und Test klären Regeln, formulieren wenige fokussierte Szenarien und prüfen sie auf der passenden Testebene. Gherkin und Cucumber sind mögliche Hilfsmittel.

Die Forschung mit 166 kartierten Fachbeiträgen stützt keine universellen BDD-Erfolgsprozente (Binamungu und Maro, 2023). Ein Team sollte daher mit 1 Story starten, eigene lokale Prozesswerte erheben und Werkzeuggrenzen schriftlich festhalten. So bleibt erkennbar, ob der gewählte Ablauf im eigenen Kontext trägt. Wenn Sie prüfen möchten, wie Autemos geklärte Testbeschreibungen in visuelle ausführbare Abläufe überführt, vereinbaren Sie ein technisches Gespräch.