Gherkin / BDD (Behavior-Driven Development)

Von nanologika | 29. Januar 2026 |

Kurz erklärt

BDD (Behavior-Driven Development) ist eine Vorgehensweise in der Softwareentwicklung, bei der Anforderungen als konkretes, erwartetes Verhalten beschrieben werden – so, dass Fachbereich, Entwicklung und QA/Test dasselbe Verständnis teilen.
Gherkin ist die dafür häufig genutzte Text-Syntax, mit der diese Verhaltensbeschreibungen in einer standardisierten Form formuliert werden (meist nach dem Muster Given – When – Then).

Wofür wird das eingesetzt?

BDD/Gherkin wird genutzt, um:

Akzeptanzkriterien eindeutig und prüfbar zu formulieren,
Missverständnisse zwischen Stakeholdern zu reduzieren,
Anforderungen als „lebende Dokumentation“ zu pflegen,
eine gute Grundlage für automatisierte Tests zu schaffen.

Wie sieht Gherkin aus?

Gherkin-Szenarien beschreiben Beispiele aus Nutzersicht:

Feature: Benutzer-Login

  Scenario: Login mit gültigen Zugangsdaten
    Given der Nutzer ist auf der Login-Seite
    When er gültige Zugangsdaten eingibt
    And auf "Anmelden" klickt
    Then wird die Startseite angezeigt
    And der Nutzername ist sichtbar

Lesart:

Given (Gegeben): Ausgangssituation/Kontext
When (Wenn): Aktion/Ereignis
Then (Dann): Erwartetes Ergebnis (prüfbar)

Vorteil in der Praxis

Gemeinsame Sprache: verständlich für Nicht-Techniker:innen und Technikteam
Klare Definition von „fertig“: Akzeptanzkriterien sind direkt abgeleitet
Höhere Qualität: frühes, strukturiertes Feedback durch Beispiele
Nachvollziehbarkeit: Anforderungen bleiben nachvollziehbar, weil sie testbar formuliert sind

Best Practices

Szenarien fachlich formulieren (nicht zu UI-/Implementierungsnah)
Pro Szenario ein Verhalten beschreiben
Then nur mit messbaren/prüfbaren Ergebnissen füllen
Einheitliche Begriffe verwenden (Domänensprache)

Beispiel (Produkt-/Angebotskonfigurator)

Bei nanoLogika drehen sich viele Anwendungsfälle um regelbasierte Produktkonfiguration, automatisierte Angebotserstellung (inkl. Variantenlogik, Stücklisten) und die Übergabe in nachgelagerte Systeme/Prozesse (z. B. ERP/CRM bzw. Prozess-Orchestrierung).

Gherkin-Beispiel: B2B-Angebot mit gültiger Konfiguration, Preis & Stückliste

Feature: Angebotskonfigurator (B2B) – gültige Konfiguration erzeugt Angebot

  Background:
    Given ein Produktkatalog enthält Produktbestandteile, Preise und Kombinationsregeln
    And das Regelwerk prüft Abhängigkeiten in Echtzeit und berechnet Preise korrekt
    And ein Angebotsprozess kann aus dem Konfigurator heraus ausgelöst werden (z. B. Übergabe an ERP oder Versand per E-Mail)

  Scenario: Nutzer erstellt ein fehlerfreies Angebot trotz Variantenvielfalt
    Given der Nutzer konfiguriert ein variantenreiches Produkt
    When er Optionen auswählt, die gemäß Regelwerk kombinierbar sind
    Then bleibt die Konfiguration konsistent und regelkonform
    And der Gesamtpreis wird korrekt berechnet
    And eine Stückliste wird aus der Konfiguration erzeugt
    And der Angebotsprozess wird gestartet und die Angebotsdaten werden übergeben

Warum passt das zu nanoLogika?

nanoLogika adressiert explizit die Angebotserstellung bei Variantenvielfalt und komplizierten Stücklisten – mit dem Ziel „fehlerfrei“ und schnell zu sein.
In produktLogika® ist die Echtzeit-Regelprüfung inkl. korrekter Preisberechnung sowie das Erzeugen von Stücklisten und das Auslösen von Prozessen (z. B. E-Mail/ERP) als typisches Muster beschrieben.

Optionales Zusatzszenario

Ungültige Kombination wird verhindert (Regelwerk greift)

Scenario: Ungültige Optionen werden blockiert
  Given der Nutzer hat eine Option gewählt, die andere Optionen ausschließt
  When er eine nicht kombinierbare Option auswählt
  Then wird die Auswahl verhindert oder als ungültig markiert
  And der Konfigurator zeigt einen Hinweis zur Regelverletzung
  And es kann kein Angebot ausgelöst werden, solange die Konfiguration ungültig ist

Das bildet genau den Nutzen „regelbasierte Konfiguration für sichere Ergebnisse“ ab.

Wenn ihr Prozessautomatisierung (Camunda) im Glossar-Beispiel zeigen wollt

Scenario: Angebot durchläuft einen Freigabe-Workflow
  Given das Angebot überschreitet einen vordefinierten Schwellenwert
  When der Nutzer das Angebot anfragt
  Then startet ein modellierter Workflow zur Freigabe (BPMN)
  And nach Freigabe werden Angebotsdaten an das Zielsystem übergeben

nanoLogika positioniert explizit Prozessmodellierung/-automatisierung (Camunda/BPMN) als Leistungsbaustein – das lässt sich gut als „BDD-Szenario“ zeigen.

« Back to Glossary Index