·
9 min
BDD Testing: Vom gemeinsamen Beispiel zum ausführbaren Test
Roman Kirchmeier - Autemos
BDD Testing prüft Software anhand fachlicher Verhaltensbeispiele, die ein Team vor der Umsetzung gemeinsam festlegt. Es gehört zum grösseren Prozess des Behavior Driven Development: Fachseite, Entwicklung und Testing klären eine Regel, wählen aussagekräftige Beispiele und verbinden diese später mit ausführbaren Prüfungen. Die Testebene kann eine Komponente, API, Integration oder Benutzeroberfläche sein. Der aktuelle ISTQB-Lehrplan ordnet BDD den testgetriebenen Entwicklungsansätzen zu, bei denen Tests vor dem Produktionscode entstehen (ISTQB, 2024). Ein bestandener Test bestätigt das vereinbarte Beispiel. Er beweist keine vollständige Abdeckung.
Kurz gefasst: BDD Testing überführt gemeinsam geklärte Beispiele in ausführbare Prüfungen. Ein belastbarer Ablauf umfasst 7 Schritte, vom kleinen Arbeitspaket bis zur gepflegten Automation. Die passende Prüfung läuft auf der kleinsten sinnvollen Testebene. Wenige UI-Tests sichern zentrale Abläufe, viele schnelle Prüfungen kontrollieren Regeln näher am Code.
Abbildung 1: Sechs Stationen vom fachlichen Beispiel bis zum Testbericht.
Was ist BDD Testing?
BDD Testing ist die Testpraxis rund um konkrete Verhaltensbeispiele, die Fachseite, Entwicklung und Testing vor der Umsetzung abstimmen. Ein Beispiel beschreibt Ausgangslage, Ereignis und beobachtbares Ergebnis. Cucumber gliedert den Ablauf in 3 zugehörige Praktiken: Discovery, Formulation und Automation (Cucumber, 2026).
Discovery klärt Regeln und offene Fragen. Formulation hält ausgewählte Beispiele in einer lesbaren, strukturierten Form fest. Automation verbindet diese Beispiele mit dem System und liefert wiederholbare Ergebnisse. Das Werkzeug kommt erst im dritten Teil zum Einsatz. Ein nachträglich verfasster Szenariotext kann eine sinnvolle Regression sein. Gemäss Cucumber belegt dieses Vorgehen allein keinen BDD-Prozess (Cucumber, 2026).
„We call these practices Discovery, Formulation, and Automation.“ So benennt die aktuelle Cucumber-Dokumentation den dreiteiligen BDD-Zyklus (Cucumber, 2026).
BDD Testing ist weder ein bestimmtes Framework noch an Gherkin gebunden. Gherkin ist eine verbreitete Notation. Cucumber ist ein mögliches Ausführungswerkzeug. Teams können dieselben fachlichen Beispiele mit anderen Testbibliotheken umsetzen, sofern die Verbindung zwischen Regel, Beispiel und prüfbarem Ergebnis erhalten bleibt.
Wie wird aus einem Beispiel ein ausführbarer BDD-Test?
Ein ausführbarer BDD-Test entsteht in 7 Schritten, die Gespräch, Formulierung und technische Prüfung verbinden. Der Ablauf beginnt kurz vor der Umsetzung einer kleinen Änderung. Cucumber empfiehlt für einen Discovery Workshop 3 bis 6 Personen und 25 bis 30 Minuten pro Story als Richtwerte, nicht als feste Grenzen (Cucumber, 2026).
Wählen Sie eine kleine Story oder eine klar begrenzte Änderung aus dem nächsten Entwicklungsabschnitt.
Bringen Sie Produkt- oder Fachsicht, Entwicklung und Testing in ein gemeinsames Gespräch.
Sammeln Sie Regeln, positive und negative Beispiele sowie ungeklärte Fragen.
Wählen Sie wenige Beispiele, die jede Regel eindeutig erklären oder eine Grenze sichtbar machen.
Formulieren Sie pro Szenario eine Ausgangslage, ein Ereignis und ein beobachtbares Ergebnis.
Bestimmen Sie die kleinste Testebene, die dieses Verhalten zuverlässig prüfen kann.
Implementieren Sie die Prüfung vor dem zugehörigen Produktionsverhalten und pflegen Sie Spezifikation und Testcode gemeinsam.
Example Mapping gibt dem Gespräch eine einfache Ordnung: Story, Regeln, Beispiele und offene Fragen erhalten getrennte Karten. Die Methode endet, sobald der Umfang klar ist oder die vereinbarte Zeit abläuft (Cucumber, 2026). Ein zu grosses Beispiel wird geteilt. Ein ungelöster fachlicher Widerspruch bleibt als Frage sichtbar, statt still in Testcode zu verschwinden.
Welche Testebene passt zu welchem Verhalten?
Abbildung 2: Viele Komponentenprüfungen und wenige UI-Systemtests.
Die passende Testebene ist die kleinste Systemgrenze, an der sich das vereinbarte Verhalten sicher beobachten lässt. Der ISTQB-Testpyramide zufolge gehören viele kleine, isolierte und schnelle Prüfungen nach unten. Langsamere, weniger isolierte Systemprüfungen stehen weiter oben und bleiben zahlenmässig kleiner (ISTQB, 2024).
Testebene | Geeignet für | Stärke | Typisches Risiko | Auswahlregel |
|---|---|---|---|---|
Komponente oder Domäne | Fachregel ohne Infrastruktur | Schnelles, klares Ergebnis | Der Text bringt Fachlesern wenig Nutzen | Direkt am Code prüfen, wenn keine externe Wirkung nötig ist |
Service oder API | Beobachtbarer Vertrag über eine Schnittstelle | Gute Diagnose und stabile Ausführung | Testdaten können Annahmen verdecken | Vor einer UI-Prüfung bevorzugen |
Integration | Zusammenspiel realer Komponenten | Findet Protokoll- und Konfigurationsfehler | Mehr Abhängigkeiten | Auf eine Regel und wenige Systeme begrenzen |
UI-Systemtest | Kritischer Nutzerablauf und reale Verdrahtung | Sichtbare Wirkung im Gesamtsystem | Langsame Ausführung und breite Fehlerursachen | Kleine Auswahl zentraler Abläufe |
Explorativ oder manuell | Neue Risiken, Nutzbarkeit und offene Fragen | Erkennt Probleme ausserhalb bekannter Beispiele | Weniger wiederholbar | Ergänzend zu den festgelegten Beispielen einsetzen |
Ein Preislimit lässt sich meist auf Komponenten- oder API-Ebene beweisen. Ein vollständiger Zahlungsvorgang braucht möglicherweise eine Integration. Die Oberfläche ist sinnvoll, wenn Darstellung, Navigation oder reale Systemverdrahtung Teil des Verhaltens sind. Die Testpyramide liefert dafür ein Auswahlmodell; die API-Testautomatisierung zeigt typische Schnittstellenprüfungen.
Was macht ein Szenario testbar und lesbar?
Abbildung 3: Given, When und Then trennen Ausgangslage, Ereignis und Ergebnis.
Ein testbares Szenario beschreibt genau eine fachliche Regel mit Ausgangslage, einem auslösenden Ereignis und einem beobachtbaren Ergebnis. In Gherkin stehen dafür Given, When und Then. Cucumber empfiehlt 3 bis 5 Schritte pro Beispiel. Diese Zahl ist eine Lesbarkeitsregel und keine Syntaxschranke (Cucumber, 2026).
Ein Beispiel für ein Tageslimit könnte lauten: Ein Konto hat noch 1.000 CHF verfügbar. Der Kunde überweist 250 CHF. Das verbleibende Limit beträgt danach 750 CHF. Der Text nennt keine CSS-Selektoren, Klickkoordinaten oder Datenbankspalten. Solche Details gehören in die Automationsschicht.
Die Cucumber-Referenz verlangt für Then ein Ergebnis, das ein Nutzer oder externes System beobachten kann. Sie formuliert: „Then steps should use an assertion to compare the actual outcome to the expected outcome“ (Cucumber, 2026). Ein Szenario mit mehreren Regeln, Ereignissen und Ausgängen verliert seine diagnostische Aussage.
Gute Szenarien haben meist diese Merkmale:
einen fachlich benannten Zweck;
eine nachvollziehbare Ausgangslage;
ein zentrales Ereignis;
mindestens ein beobachtbares Ergebnis;
konsistente Begriffe aus der Fachdomäne;
keine technischen Bedienungsdetails.
Was beweist ein fehlgeschlagenes BDD-Szenario?
Ein fehlgeschlagenes BDD-Szenario beweist, dass das beobachtete Verhalten von der ausführbaren Spezifikation abweicht. Es lokalisiert die Ursache noch nicht. Eine Studie kartierte 166 BDD-Publikationen, fand aber nur wenige Metriken für Spezifikationen und Prozesse (Journal of Systems and Software, 2023). Logs und Traces bleiben nötig.
Ein bestandenes Szenario hat eine ebenso klare Grenze: Das konkrete Beispiel lief unter den verwendeten Daten und Bedingungen erfolgreich. Weitere Eingabeklassen, Nebenläufigkeit, Sicherheit, Leistung und unbekannte Risiken bleiben eigene Testziele. Software-Testing-Grundlagen ordnen solche Ziele in eine breitere Teststrategie ein.
Wenn ein einzelner Defekt viele fachlich unabhängige Szenarien stoppt, liegt häufig zu viel Umfang in gemeinsamen Systemtests oder im Setup. Kleinere Prüfungen trennen die Ursachen besser. Gemeinsamer statischer Zustand verschärft den Effekt, da ein Szenario die Ausgangslage des nächsten verändern kann.
Welche Fehler machen BDD-Tests teuer?
BDD-Tests werden teuer, wenn fachliche Beispiele zu technischen Skripten anwachsen oder keine klaren Eigentümer haben. Der Cucumber-Ablauf enthält 3 Praktiken und setzt Zusammenarbeit klar vor die Automation. Die Dokumentation warnt ausdrücklich vor der Gleichsetzung von Werkzeugnutzung und BDD (Cucumber, 2026).
Szenarien entstehen erst nach Abschluss des Produktionscodes.
Eine Testperson übernimmt Discovery und Formulierung allein.
Cucumber gilt fälschlich als Ersatz für fachliche Abstimmung.
UI-Selektoren und Klickfolgen stehen im Szenariotext.
Ein langer Ablauf deckt mehrere Regeln und Ausgänge ab.
Jedes Beispiel läuft durch die Benutzeroberfläche.
Szenarien teilen veränderlichen Zustand oder unklare Testdaten.
KI-Entwürfe gelangen ohne fachliche Prüfung in die Testsuite.
Wartung beginnt bei der Sprache. Derselbe Sachverhalt sollte denselben Fachbegriff verwenden. Änderungen an einer Regel brauchen eine gemeinsame Anpassung von Beispiel, erwarteter Wirkung und Automationscode. Eine hohe Zahl grüner Szenarien ersetzt keine Abdeckungsanalyse.
Kann KI BDD-Szenarien erstellen und wo passt Autemos?
Abbildung 4: KI-Entwürfe benötigen Kontext, Fachprüfung und Freigabe.
KI kann BDD-Szenarien entwerfen, braucht aber fachliche Prüfung und genügend Kontext. Eine begutachtete Studie testete GPT-3.5, GPT-4, Llama-2-13B und PaLM-2 mit Zero-Shot- und Few-Shot-Prompts; ihre positiven Ergebnisse gelten für die gewählte Auswertung und sind kein allgemeiner Zuverlässigkeitsnachweis (IEEE Access, 2024).
Ein Preprint aus dem Jahr 2026 untersuchte 500 Stories aus 4 proprietären Produkten. Eingaben aus Story plus ausführlicher Beschreibung erhielten bei 3 Modellen höhere Bewertungen als reine Story-Eingaben. Die Arbeit ist noch nicht begutachtet und taugt nicht als Branchenwert (arXiv, 2026).
Autemos kann laut aktueller Produktseite aus einem abgestimmten Jira-Ticket, einer User Story oder einer natürlichsprachlichen Testbeschreibung einen visuellen ausführbaren Workflow erzeugen. Menschen prüfen die erzeugten Schritte vor der Ausführung (Autemos, 2026). Bestehende Playwright-Prüfungen lassen sich in visuelle Test Workflows einbinden. Öffentlich belegt sind weder `.feature`-Import noch Cucumber-Ausführung.
Für den Einsatz gilt eine klare Reihenfolge:
Das Team klärt Verhalten, Regeln und Beispiele.
Fachverantwortliche bestätigen den ausgewählten Umfang.
Autemos erzeugt auf Basis der freigegebenen Beschreibung einen prüfbaren Workflow.
Ein Mensch kontrolliert Schritte, Daten, Systemzugänge und erwartete Ergebnisse.
Die Ausführung liefert diagnostische Nachweise für das vereinbarte Beispiel.
Häufig gestellte Fragen
Die 5 häufigsten Fragen betreffen Definition, Testebene, Automationsgrad, Fehlerdeutung und KI-Unterstützung. Cucumber empfiehlt 3 bis 5 Schritte pro Beispiel, behandelt diese Spanne aber als Lesbarkeitshinweis statt als Syntaxregel (Cucumber, 2026). Die Antworten unten halten Prozess, Szenario und Werkzeug kompakt getrennt.
Was ist BDD Testing?
BDD Testing prüft Software anhand konkreter Verhaltensbeispiele, die Fachseite, Entwicklung und Testing vor der Umsetzung vereinbaren. Es verbindet Discovery, strukturierte Formulierung und ausführbare Prüfungen. Cucumber beschreibt diese drei Praktiken als Discovery, Formulation und Automation (Cucumber, 2026).
Auf welcher Testebene sollten BDD-Szenarien laufen?
BDD-Szenarien sollten auf der kleinsten Testebene laufen, die das Verhalten zuverlässig beweist. Komponenten- und API-Prüfungen geben meist schnelleres, klareres Feedback. UI-Systemtests bleiben für wenige kritische Nutzerabläufe und die reale Verdrahtung des Systems reserviert.
Muss jeder BDD-Test automatisiert werden?
Im vollständigen testgetriebenen BDD-Zyklus wird das ausgewählte Beispiel vor dem Produktionsverhalten automatisiert. Discovery-Beispiele können schon vorher offene Fragen klären. Wenn eine Automatisierung keinen stabilen Nutzen bietet, sollte das Team Umfang und Testziel neu entscheiden, statt mechanisch jedes Beispiel auszuführen.
Was bedeutet ein fehlgeschlagenes BDD-Szenario?
Ein fehlgeschlagenes Szenario zeigt eine Abweichung zwischen beobachtetem Verhalten und ausführbarer Spezifikation. Die Ursache kann im Produkt, in Daten, Umgebung, Automationscode oder Spezifikation liegen. Passende Logs und Berichte sind für die Diagnose erforderlich.
Kann KI BDD-Szenarien automatisch schreiben?
KI kann einen ersten Entwurf liefern. Aktuelle Studien zeigen brauchbare Ergebnisse in begrenzten Auswertungen und deutliche Abhängigkeit von der Eingabequalität. Fachliche Prüfung bleibt erforderlich, da ein sprachlich korrektes Szenario falsche Regeln oder fehlende Grenzfälle enthalten kann.
Fazit
BDD Testing verbindet ein vereinbartes Verhalten mit prüfbaren Ergebnissen. Der beschriebene Ablauf hat 7 Schritte, vom kleinen Arbeitspaket bis zur gemeinsamen Wartung. Cucumber ordnet diese Arbeit den 3 Praktiken Discovery, Formulation und Automation zu (Cucumber, 2026). Die Testebene bleibt eine bewusste Architekturentscheidung.
Klären Sie Regeln und Grenzfälle mit den drei nötigen Perspektiven. Setzen Sie jedes Beispiel auf der kleinsten sinnvollen Testebene um und halten Sie wenige UI-Systemtests für zentrale Nutzerabläufe. Ein Fehlerbericht ist ein Diagnoseeingang, keine fertige Ursachenanalyse. KI kann Formulierungen vorbereiten, doch Fachverantwortliche entscheiden über Inhalt und Freigabe. Autemos kann genehmigte Beschreibungen in visuelle Workflows überführen und bestehende Playwright-Prüfungen einbinden. Für eine konkrete Einordnung Ihrer Testarchitektur und vorhandenen Artefakte sprechen Sie mit dem Autemos-Team.
