Behavior Driven Development

Was bedeutet verhaltensgetriebene Entwicklung?

Die verhaltensgetriebene Entwicklung überführt fachliche Anforderungen in konkrete Beispiele für das erwartete Verhalten einer Software. Im Mittelpunkt steht die Frage, wie ein System aus Sicht des Nutzers oder eines anderen beteiligten Systems auf eine bestimmte Ausgangslage und Aktion reagieren soll.

Die gebräuchliche Abkürzung BDD bezeichnet einen kollaborativen Entwicklungsansatz, der Anforderungen, Programmierung und Qualitätssicherung miteinander verbindet. Die Szenarien werden vor oder während der Umsetzung gemeinsam abgestimmt, damit alle Beteiligten dasselbe Verständnis von einer Funktion entwickeln.

BDD-Szenarien werden häufig als ausführbare Spezifikationen bezeichnet. Werden sie mit dem Programmcode und einem geeigneten Testwerkzeug verbunden, lassen sie sich automatisiert ausführen. Ein erfolgreich absolviertes Szenario bestätigt, dass die geprüfte Funktion das vereinbarte Verhalten zeigt.

Wie funktioniert BDD mit Angenommen, Wenn und Dann?

Ein BDD-Szenario beschreibt eine fachliche Situation in einer strukturierten, möglichst allgemein verständlichen Sprache. Verbreitet ist die Given-When-Then-Syntax, die auf Deutsch als Angenommen-Wenn-Dann-Schema formuliert werden kann.

• Angenommen definiert den Ausgangszustand und die erforderlichen Voraussetzungen.
• Wenn beschreibt die Aktion, das Ereignis oder die Eingabe, die das Verhalten auslöst.
• Dann legt das fachlich erwartete Ergebnis fest, das anschließend überprüft werden kann.

Für einen Onlineshop könnte ein Szenario lauten: Angenommen, ein Produkt ist nicht lieferbar. Wenn ein Nutzer die Produktseite aufruft, dann wird anstelle des Kaufbuttons ein Hinweis zur Nichtverfügbarkeit angezeigt. Die Beschreibung definiert ein beobachtbares Ergebnis, ohne eine konkrete technische Implementierung vorzuschreiben.

Welche Funktion hat Gherkin?

Gherkin ist eine strukturierte Beschreibungssprache für BDD-Szenarien. Sie verwendet Schlüsselwörter wie Feature, Scenario, Given, When, Then, And und But. Werkzeuge wie Cucumber können diese Beschreibungen mit ausführbarem Testcode verbinden und die Resultate in einem Testbericht darstellen.

Eine Feature-Datei bündelt mehrere Szenarien zu einer fachlich zusammengehörenden Funktion. Ein Szenario bildet einen konkreten Anwendungsfall ab, während sogenannte Scenario Outlines denselben Ablauf mit mehreren Datensätzen prüfen können.

Wie läuft ein verhaltensgetriebener Entwicklungsprozess ab?

Der BDD-Prozess beginnt mit einem gemeinsamen Gespräch über eine Anforderung. Fachverantwortliche, Entwickler und Tester sammeln Beispiele, klären Sonderfälle und bestimmen, welches sichtbare Ergebnis als korrekt gilt. Dieses Vorgehen wird häufig als Three-Amigos-Ansatz bezeichnet.

• Das Team grenzt den fachlichen Nutzen und den betroffenen Nutzerprozess ab.
• Konkrete Beispiele verdeutlichen normale Abläufe, Grenzfälle und Fehlerzustände.
• Aus den Beispielen entstehen präzise Akzeptanzkriterien und BDD-Szenarien.
• Entwickler implementieren die Funktion und verbinden Szenarioschritte mit Testcode.
• Automatisierte Tests prüfen die vereinbarten Verhaltensweisen bei jeder relevanten Änderung.
• Die Szenarien werden zusammen mit der Software gepflegt und bilden eine aktuelle Funktionsdokumentation.

Die Automatisierung ist ein möglicher, aber nicht der einzige Nutzen von BDD. Bereits das gemeinsame Formulieren konkreter Beispiele deckt widersprüchliche Anforderungen, unklare Begriffe und fehlende Sonderfälle auf, bevor daraus Programmcode entsteht.

Unterschiede zwischen BDD, TDD und Akzeptanztests

Der Unterschied zwischen BDD und Test Driven Development, kurz TDD, liegt vor allem in der Betrachtungsebene. TDD beginnt meist mit einem technischen Test für eine kleine Programmeinheit. BDD beschreibt dagegen fachlich beobachtbares Verhalten anhand konkreter Nutzungssituationen.

BDD ersetzt weder Unit-Tests noch technische Integrations- und Sicherheitstests. Ein fachliches Szenario kann korrekt durchlaufen, obwohl im Hintergrund Leistungsprobleme, fehlerhafte Schnittstellen oder Sicherheitslücken bestehen. Deshalb bleibt eine abgestufte Teststrategie erforderlich.

Welche Bedeutung hat BDD für SEO, SEA und GEO?

BDD unterstützt SEO-Projekte, wenn technische Anforderungen an Websites eindeutig und automatisiert überprüfbar sein sollen. Szenarien können beispielsweise festlegen, wie Canonical-Tags, Weiterleitungen, strukturierte Daten, Meta-Robots-Angaben oder Statuscodes unter bestimmten Bedingungen ausgegeben werden müssen.

Bei einem Website-Relaunch lässt sich etwa definieren: Angenommen, eine alte URL besitzt ein neues Ziel. Wenn ein Crawler die alte Adresse aufruft, dann liefert der Server eine permanente Weiterleitung zur festgelegten neuen URL. Solche Kriterien ergänzen eine strukturierte SEO-Checkliste für den Website-Relaunch.

Im SEA-Umfeld eignet sich BDD für Regeln in Landingpages, Produktfeeds und Conversion-Prozessen. Ein Szenario kann prüfen, ob eine Kampagnen-Landingpage den erwarteten Inhalt zeigt, Tracking-Ereignisse bei einer definierten Aktion auslöst oder nicht verfügbare Angebote korrekt behandelt. Die fachliche Kampagnenlogik bleibt dadurch für Marketing und Entwicklung nachvollziehbar.

Für GEO, die Generative Engine Optimization, können BDD-Szenarien technische und redaktionelle Ausgaberegeln absichern. Prüfbar sind beispielsweise vollständige strukturierte Daten, konsistente Unternehmensangaben oder die korrekte Bereitstellung zitierfähiger Inhalte. Die Auswahl geeigneter Themen und Quellen bleibt eine strategische Aufgabe, wie sie auch eine individuelle GEO-Optimierung umfasst.

Typische Fehler bei BDD-Szenarien

Ungeeignete Szenarien beschreiben häufig interne Arbeitsschritte statt beobachtbarer Ergebnisse. Eine Vorgabe wie „Dann wird Methode X ausgeführt“ ist für Fachverantwortliche schwer bewertbar und bindet den Test unnötig an die aktuelle Programmstruktur.

• Ein Szenario prüft mehrere unabhängige Verhaltensweisen und erschwert dadurch die Fehleranalyse.
• Unbestimmte Begriffe wie schnell, korrekt oder benutzerfreundlich enthalten kein messbares Akzeptanzkriterium.
• Zu viele technische Details machen die Spezifikation für Marketing, Produktmanagement und Fachabteilungen unverständlich.
• Seltene Grenzfälle fehlen, obwohl sie rechtliche, finanzielle oder technische Folgen verursachen können.
• Veraltete Szenarien widersprechen dem aktuellen Produktverhalten und verlieren ihren Wert als Dokumentation.

Ein BDD-Szenario ist hochwertig, wenn ein fachkundiger Leser eindeutig beurteilen kann, ob das beschriebene Ergebnis eingetreten ist. Für Aussagen zur Ladezeit, Indexierbarkeit oder Datenqualität müssen daher konkrete Bedingungen und überprüfbare Resultate festgelegt werden.

Häufige Fragen zur verhaltensgetriebenen Entwicklung

Fragen zur technischen Qualität deiner Website oder zur Abstimmung von SEO-, SEA- und GEO-Anforderungen? Die kostenlose Erstberatung bietet eine fachliche Einordnung durch einen persönlichen Experten mit mindestens 14 Jahren Erfahrung. Die OSG gehört zu den aktuell acht in Deutschland für SEO und SEA BVDW-zertifizierten Agenturen.