BDD-Testing: Behavior-Driven Development einfach erklärt

BDD-Testing (Behavior-Driven Development, also verhaltensgetriebene Entwicklung) ist eine Methode, Testszenarien in klarer, strukturierter Sprache im Given/When/Then-Format zu schreiben, damit Entwickler, QA-Ingenieure und Fachverantwortliche dieselbe Spezifikation lesen und abstimmen können, bevor ein Feature ausgeliefert wird. Tools wie Cucumber führen diese Szenarien anschließend als automatisierte Tests gegen das echte Produkt aus.

Ob Ihr Team BDD-Testing braucht, hängt an einer Frage: Sollte jemand, der nie Code geschrieben hat, Ihre Tests lesen können? Mit BDD kann ein Produktmanager „Angenommen ein angemeldeter Nutzer, Wenn er einen Artikel in den Warenkorb legt, Dann wird die Warenkorbsumme aktualisiert“ lesen, weiß genau, was geprüft wird, und erkennt, was fehlt. Diese Lesbarkeit hat ihren Preis. Hinter jeder Zeile in Alltagssprache steckt Code, und jemand muss beides synchron halten, während sich das Produkt verändert.

BDD ist in Testteams inzwischen gängige Praxis. In der Umfrage State of Testing 2024 von PractiTest und Tea-time with Testers stieg die BDD-Nutzung von 19 % der Befragten im Jahr 2022 auf 26 % im Jahr 2024, knapp vor testgetriebener Entwicklung (TDD) mit 23 %, und 92 % der Befragten arbeiteten nach agilen oder agil geprägten Modellen.

Dieser Leitfaden erklärt die Given/When/Then-Struktur, wie sich BDD-Tools in automatisiertes Testen einfügen, wie sich BDD von TDD unterscheidet und wann sich der zusätzliche Aufwand lohnt.

Die Given/When/Then-Struktur in BDD

Jedes BDD-Szenario folgt derselben dreiteiligen Form:

• Given (Angenommen) legt den Ausgangszustand fest: wer der Nutzer ist, welche Daten vorhanden sind, auf welchem Bildschirm er sich befindet.
• When (Wenn) beschreibt die eine Aktion oder das eine Ereignis, das getestet wird.
• Then (Dann) nennt das erwartete Ergebnis, auf das es dem Fachbereich ankommt.

And (Und) und But (Aber) erweitern jeden der drei Teile, wenn ein Schritt mehr als eine Zeile braucht. Die Syntax heißt Gherkin und steht in reinen Textdateien mit der Endung .feature, die jeder im Team öffnen kann. Die Gherkin-Referenz listet alle Schlüsselwörter auf, die in mehr als 70 Sprachen übersetzt sind: Mit der Zeile # language: de am Anfang der Datei schreibt Ihr Team die Szenarien auf Deutsch.

So sieht das Warenkorb-Beispiel als echtes Szenario aus:

# language: de
Funktionalität: Warenkorb

  Szenario: Ein hinzugefügter Artikel aktualisiert die Warenkorbsumme
    Angenommen ein angemeldeter Nutzer mit leerem Warenkorb
    Wenn er ein Notizbuch für 25 € in den Warenkorb legt
    Dann zeigt der Warenkorb 1 Artikel
    Und die Warenkorbsumme beträgt 25,00 €

Ein Product Owner kann bestätigen, dass genau dieses Verhalten gewollt ist, ein Entwickler kann danach bauen und ein QA-Ingenieur kann es automatisieren, alles auf Basis desselben Textes.

Die Kunst liegt darin, Verhalten statt Klicks zu beschreiben. „Wenn er auf den Button mit der id add-to-cart klickt“ bindet das Szenario an die heutige Oberfläche und bricht beim nächsten Redesign. „Wenn er ein Notizbuch für 25 € in den Warenkorb legt“ übersteht ein Redesign und liest sich weiterhin wie eine Geschäftsregel. Scenario Outlines (Szenariogrundrisse) gehen noch weiter: Ein Szenario plus eine Tabelle mit Beispielwerten deckt zehn Rabattcodes oder fünf Benutzerrollen ab, ohne zehn Kopien derselben Schritte.

Diese eine, lesbare Quelle der Wahrheit setzt an einer verbreiteten Schwäche an. Dieselbe Umfrage State of Testing 2024 ergab, dass in 60 % der Organisationen Testfälle nicht gut geschrieben und gepflegt sind, meist wegen Duplikaten und mangelnder Pflege.

Wie BDD-Testing-Tools tatsächlich funktionieren

BDD-Tools sitzen auf Ihrem Testautomatisierungs-Framework und überlassen ihm die eigentliche Arbeit. Die Szenarien beschreiben, was das Produkt tun soll, und das darunterliegende Framework führt jeden Schritt im Browser, in der mobilen App oder über die API aus. Teams mit einer bestehenden automatisierten Testsuite können eine BDD-Ebene meist schrittweise ergänzen, einen Geschäftsablauf nach dem anderen, und ihre vorhandenen Tests behalten. Ein BDD-Setup hat drei Ebenen:

Cucumber ist das meistgenutzte BDD-Tool, mit Implementierungen für Java, JavaScript, Ruby und weitere Sprachen. Behave deckt Python ab, Reqnroll (der Nachfolger von SpecFlow) deckt .NET ab, und CodeceptJS unterstützt Gherkin-Szenarien für JavaScript-Teams. Für API-Tests nutzt Karate direkt eine Gherkin-ähnliche Syntax, ein Grund, warum es oft zur Sprache kommt, wenn Teams Karate mit REST-Assured vergleichen.

Wenn Cucumber Wenn er ein Notizbuch für 25 € in den Warenkorb legt ausführt, sucht es die passende Step Definition, die wiederum Playwright oder Selenium aufruft, um die Aktion auszuführen. Diese Schichtung hat zwei praktische Folgen:

• BDD übernimmt die Qualität des darunterliegenden Frameworks. Instabile Locators oder langsame Testumgebungen bleiben auch hinter einem lesbaren Szenario instabil und langsam.
• Auch Nicht-Programmierer können am Testdesign mitwirken. In der Umfrage von 2024 gaben 42 % der Befragten an, sich beim Schreiben von Automatisierungsskripten nicht sicher zu fühlen. Szenarien in Alltagssprache erlauben es diesen Testern und den Produktverantwortlichen, festzulegen, was automatisiert wird, während Ingenieure den Code der Schritte verantworten.

BDD-Szenarien dienen als lesbare Oberfläche für automatisierte Funktionstests: Sie prüfen durchgängig, ob sich Features so verhalten, wie der Fachbereich es erwartet.

BDD vs. TDD: Was ist der Unterschied?

BDD ist Mitte der 2000er-Jahre aus der testgetriebenen Entwicklung (TDD) hervorgegangen, als Dan North begann, Tests als Verhalten zu beschreiben, um TDD leichter vermitteln und diskutieren zu können. Heute lösen beide unterschiedliche Probleme.

Bei der testgetriebenen Entwicklung schreibt ein Entwickler einen kleinen, fehlschlagenden Unit-Test, schreibt gerade so viel Code, dass er besteht, und refaktoriert dann. Die Tests stehen im Code und richten sich an andere Entwickler. BDD hebt das Gespräch eine Ebene höher, auf ein Verhalten, das ein Kunde oder Fachverantwortlicher wiedererkennen würde.

Viele Teams nutzen beides: TDD für die Interna und BDD für die wenigen Geschäftsabläufe, die Stakeholder freigeben müssen. Der stetige Anstieg beider Praktiken zeigt, dass „All Team Testing“ an Boden gewinnt, bei dem Entwicklung, QA und Produkt sich die Verantwortung für Qualität in den F&E-Teams teilen.

Wann sich der Aufwand für BDD-Testing lohnt

BDD bedeutet echte Zusatzarbeit über die Automatisierung hinaus. Jemand muss kurze Szenario-Sitzungen mit Produkt, Entwicklung und QA durchführen (oft „Three Amigos“-Meetings genannt), ein gemeinsames Vokabular an Schritten pflegen, damit Szenarien nicht zu Beinahe-Duplikaten auseinanderlaufen, und die Step Definitions anpassen, wenn sich die Oberfläche ändert. Wenn niemand außerhalb der Entwicklung die Szenarien liest, bringt diese Arbeit nichts.

BDD zahlt sich in der Regel aus, wenn:

• Geschäftsregeln komplex oder umstritten sind. Preise, Anspruchsvoraussetzungen, Berechtigungen und Erstattungslogik sind die Quelle von Fehlern nach dem Muster „So war das nicht gemeint“.
• Nicht-technische Personen das Verhalten freigeben. Product Owner, Compliance-Verantwortliche oder das Abnahmeteam eines Kunden können Szenarien direkt prüfen.
• Manuelle QA-Ingenieure zur Automatisierung beitragen sollen, ohne zu Vollzeit-Programmierern zu werden.
• Sie lebende Dokumentation brauchen. Szenarien, die in der CI/CD laufen, zeigen, was das Produkt heute tut, was beim Onboarding und bei Audits hilft.

Meist ist es die falsche Wahl, wenn:

• die Testsuite nur für Entwickler gedacht ist: Unit-Tests, interne Bibliotheken, Infrastrukturcode.
• das Produkt ein sich schnell ändernder Prototyp ist und sich das Verhalten wöchentlich verschiebt.
• es noch keine stabile Automatisierungsbasis gibt. Erst das Framework reparieren, dann die lesbare Ebene ergänzen.

Im Kern geht es um Kommunikation. In der PractiTest-Umfrage von 2025 stiegen Kommunikationsfähigkeiten von 59 % im Jahr 2024 auf 75 % im Jahr 2025 und wurden damit zur wichtigsten Fähigkeit, die Tester nach eigener Aussage brauchen. Die Autoren führen das darauf zurück, dass Tester eng mit funktionsübergreifenden Agile- und DevOps-Teams zusammenarbeiten. BDD macht aus dieser Zusammenarbeit ein konkretes Artefakt, und ein Missverständnis, das im Szenario-Review auffällt, kostet weit weniger als eines, das erst in der Produktion auffällt. Dieselbe Kostenkurve erklärt auch die Bedeutung von QA ab den frühen Phasen der Entwicklung.

Wie QAwerk BDD in einem echten Projekt einsetzt

Bei Evolv, einer KI-gestützten Plattform zur Optimierung von digitalem Wachstum, nutzte das Team des Kunden bereits CucumberStudio als BDD-Kollaborationstool für manuelle Testfälle. Die Automatisierung von QAwerk lief auf CodeceptJS mit Puppeteer. Statt ein Tool durch das andere zu ersetzen, bauten unsere Ingenieure einen kleinen Generator, der den Verbindungscode zwischen CucumberStudio und dem CodeceptJS-Projekt in beide Richtungen erzeugt, wobei die Szenarien in der CI/CD-Pipeline laufen.

Das Ergebnis machte die Automatisierung für das gesamte QA-Team zugänglich:

• Manuelle QA-Ingenieure bauen neue Szenarien aus einer Bibliothek von mehr als 100 Action Words, mit minimaler Einarbeitung.
• Ändert sich ein Locator oder die Reihenfolge der Schritte, korrigieren sie das, indem sie Schritte in CucumberStudio bearbeiten, statt Codeänderungen zu pushen.
• Low-Level-Schritte werden nach und nach in Gherkin-Formulierungen auf Geschäftsebene umgebaut, die das Team von Evolv lesen kann.

Es funktionierte, weil beide Teams wie eines arbeiteten. Das Team von Evolv erstellte Debugging-Dokumentation, während wir Testfälle schrieben, und wir stiegen in der jeweiligen Phase der Plattform ein, von der älteren Web-App bis zum neuen Produkt. Wenn Sie unsicher sind, ob BDD zu Ihrem Projekt passt, erzählen Sie uns, was Sie entwickeln, und Sie bekommen eine klare Antwort.

Ist BDD-Testing das Richtige für Ihr Team?

BDD rechtfertigt seinen Aufwand, wenn es eine echte Kommunikationslücke zwischen denen schließt, die Software bauen, und denen, die entscheiden, was sie tun soll. Es löst ein anderes Problem als TDD, und viele starke Teams nutzen das eine, das andere oder beides.

Die Automatisierungsingenieure von QAwerk können Cucumber oder ein anderes BDD-Tool auf das Framework aufsetzen, das bereits zu Ihrem Stack passt, sodass Sie lesbare Szenarien bekommen, ohne Ihre Testsuite neu aufzubauen. Wenn Sie lieber ein dediziertes Testteam möchten, das Szenarien mit Ihren Product Ownern schreibt und sie in der CI am Laufen hält, beginnen wir in der Regel genau so.

Häufige Fragen

Erfahren Sie, wie wir eine KI-Lösung für digitales Wachstum getestet und die Geschwindigkeit der Regressionstests um 50 % gesteigert haben

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie erhalten