Verständliche Tests mit Gherkin im Klartext (Teil 1)
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.
🧭 Nächste Schritte
Willst du lernen, wie du mit Cypress elegante E2E-Tests schreibst? Dann schau dir unsere Codesurfer-Kurse an.
