Verständliche Tests mit Gherkin im Klartext ...

In einem agilen Projekt kommt es darauf an, dass alle dieselbe Sprache sprechen – egal ob Product Owner, Developer oder QA. Gherkin ist genau dafür gemacht: Es bringt Fachlichkeit, Technik und Test in einen gemeinsamen Dialog.

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

Das ist nicht nur effizient, sondern wirkt wie eine Art „Vorab-Dokumentation", die die Implementierung erleichtert und die spätere Abnahme unterstützt. Alle Beteiligten sprechen dieselbe Sprache – und genau das macht den Unterschied.

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

Beispiel:

Feature: Login

  Scenario: Benutzer loggt sich erfolgreich ein
    Given der Benutzer befindet sich auf der Startseite
    When der Benutzer klickt auf das Login-Symbol
    And der Benutzer gibt E-Mail und Passwort ein
    And der Benutzer klickt auf „Login"
    Then erscheint das Benutzer-Avatar mit den Initialen

Klingt fast wie eine gute User Story – und das ist gewollt. Denn Gherkin ist kein Tech-Tool, sondern ein Kommunikationstool.

2. Wann Gherkin für Tests richtig glänzt

Nicht jeder Test braucht Gherkin. Aber bei End-to-End-Szenarien mit klarer User Journey entfaltet es seine Stärken:

✅ Ideal für:

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

❌ Weniger geeignet für:

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

Wenn du Tests formulierst, die auch ein Nicht-Entwickler versteht, dann bist du auf dem richtigen Weg.

3. Best Practices für Gherkin (Teil 1)

Ein paar Grundprinzipien, bevor es in Teil 2 an die technischen Details geht:

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 Mustermann klickt auf Login" ist klarer als „User submits form"

Alles, was du in Teil 1 lernst, kannst du direkt in deinem Projekt anwenden – zum Beispiel bei der Vorbereitung von Testfällen oder im Austausch mit dem Product Owner. Die eigentliche Automatisierung auf Basis von Gherkin kannst du später als nächste Ausbaustufe angehen – in Teil 2 zeige ich dir, wie du Gherkin mit Cypress kombinierst, um daraus automatisierte, robuste End-to-End-Tests zu machen.

4. Fazit: Gherkin als Brücke zwischen Fachlichkeit und Tests

Gherkin ist kein Tool – es ist ein Kommunikationsmittel. In Verbindung mit einem klaren Test-Framework wird daraus eine starke Basis für gut verständliche, wartbare und praxisnahe End-to-End-Tests.

Wenn du beginnst, Tests fachlich nachvollziehbar zu beschreiben, entwickelst du nicht nur bessere Tests – sondern schaffst eine gemeinsame Grundlage im Team.