Gherkin einfach erklärt: Testszenarien mit Given, When und Then

Der Product Owner nennt es „Anmeldung“, die Entwicklung „Auth-Flow“ und im Testfall steht „Login-Szenario 3“. Alle meinen dasselbe und reden trotzdem aneinander vorbei. Gherkin ist genau für dieses Problem gemacht: Es bringt Fachlichkeit, Technik und Test in einen gemeinsamen Dialog.

Bereits in der frühen Phase, ob beim Story-Writing, in Refinements oder im Sprint-Planning, sorgt Gherkin für Klarheit. Es hilft, Anforderungen präzise zu formulieren und Missverständnisse früh aufzudecken. So entsteht ein gemeinsames Verständnis im Team.

Das wirkt wie eine Art „Vorab-Dokumentation“. Sie erleichtert die Implementierung und unterstützt die spätere Abnahme. Alle Beteiligten sprechen dieselbe Sprache.

1. Gherkin einfach erklärt

Gherkin ist eine textbasierte Sprache für das Schreiben von Testszenarien. Das Herzstück sind drei einfache Keywords:

• Given: beschreibt den Ausgangszustand
• When: beschreibt die Aktion
• Then: beschreibt das erwartete Ergebnis

Ein Szenario für den Login sieht zum Beispiel so aus:

Feature: Login

  Scenario: Registrierter Benutzer meldet sich an
    Given Max hat ein Konto mit der E-Mail max@example.com
    When Max sich mit E-Mail und Passwort anmeldet
    Then sieht Max seinen Avatar mit den Initialen „MM“

Das klingt fast wie eine gute User Story, und das ist gewollt. Gherkin soll vor allem die Verständigung im Team erleichtern.

2. Wann sich Gherkin lohnt

Nicht jeder Test braucht Gherkin. Seine Stärken zeigt es bei E2E-Szenarien mit einer klaren User Journey. Gut geeignet ist es für:

• Login, Registrierung, Checkout, Navigation
• Zusammenarbeit mit Product Ownern oder UX
• Review-Freigaben auf Fachseite

Stell dir vor, die Fachabteilung liest das Checkout-Szenario und merkt sofort, dass der Fall mit Gutscheincode fehlt. Diese Lücke fällt auf, bevor eine Zeile Code geschrieben ist. Weniger geeignet ist Gherkin dagegen für:

• rein technische Tests (z. B. API Contracts)
• Unit-Tests

Wenn du Tests formulierst, die auch ein Nicht-Entwickler versteht, bist du auf dem richtigen Weg. Welche Testebene zu welchem Risiko passt, beschreibe ich im Artikel Wie viel Testen ist genug?

3. Best Practices für Gherkin

Ein paar Grundprinzipien helfen dir beim Schreiben guter Szenarien:

• Einfach halten: Ein Szenario beschreibt genau einen Ablauf
• Fachlich statt technisch denken: Was tut der Nutzer, nicht welche Elemente werden geklickt
• Szenarien nachvollziehbar formulieren: Denk in logischen Handlungen, nicht in Klickfolgen oder Oberflächenelementen
• Verständliche Sprache nutzen: „Max meldet sich an“ ist klarer als „User submits login form“

Das alles kannst du direkt anwenden, etwa beim Vorbereiten von Testfällen oder im Gespräch mit dem Product Owner. Der nächste Schritt ist, die Szenarien zu automatisieren, zum Beispiel mit Playwright. Dafür verknüpfst du jeden Schritt mit Testcode, der genau das tut, was der Satz beschreibt.

Fazit: Gherkin als Brücke zwischen Fachlichkeit und Tests

Gherkin ist vor allem ein Kommunikationsmittel. Zusammen mit einem Test-Framework wird daraus eine gute Basis für verständliche und wartbare E2E-Tests. Wer Tests fachlich nachvollziehbar beschreibt, schafft außerdem eine gemeinsame Grundlage im Team.

Probier es beim nächsten Refinement aus. Formuliere die Akzeptanzkriterien einer User Story gemeinsam mit dem Product Owner als Given, When und Then. Oft tauchen dabei schon die ersten offenen Fragen auf. Wie du daraus E2E-Tests mit Playwright machst, zeigen wir in der Schulung Testautomatisierung für Einsteiger mit Playwright.