Mit Gherkin-Szenarien schnell und einfach Akzeptanzkriterien und Abnahmetests erstellen

Gherkin-Szenarien ebnen den Weg für automatisierte Benutzerakzeptanztests (UAT)

Domänenspezifische Sprachen wie die Gherkin-Sprache drücken Akzeptanzkriterien und Akzeptanztestfälle in einem Format aus, das sowohl für Stakeholder einfach zu verwenden als auch für Softwareprogrammierer leicht in Code zu übersetzen ist.

Was ist der Unterschied zwischen User Stories und Gherkin Szenarien?

• User Stories drücken einen Geschäftsbedarf aus.
• Gherkin Szenarien beschreiben bestimmte Fallbeispiele, anhand derer überprüft werden kann, ob die User Story korrekt umgesetzt wurde.

Das Schreiben von Gegeben-Wenn-Dann Szenarien macht automatisierte User Acceptance Tests (UAT) viel einfacher. Cucumber, das am weitesten verbreitete Open-Source-Framework für Softwaretests, unterstützt Gherkin-Testfälle, die in der Given-When-Then-Syntax geschrieben sind.

Was sind Gegeben-Wenn-Dann-Akzeptanzkriterien und Gherkin UAT-Szenarien

Das Gherkin-Framework ist ein Kommunikationstool, das Stakeholdern hilft, ihre Wünsche und Bedürfnisse gegenüber dem IT-Team auszudrücken. Viele Entwickler glauben, dass Gherkin-Akzeptanzkriterien und Benutzerabnahme-Testszenarien die wirklichen Benutzeranforderungen sind, die die IT benötigt.

Die Begriffe Akzeptanzkriterien und Akzeptanztests werden oft synonym verwendet, sind aber nicht dasselbe. Obwohl beide Begriffe die Konnotation von Akzeptanz tragen, unterscheiden sie sich in ihren Definitionen:

• Benutzerakzeptanzkriterien (oder Abnahmekriterien) spezifizieren die funktionalen und nicht-funktionalen Anforderungen, die erfüllt sein müssen, bevor eine Story von den Stakeholdern als abgeschlossen betrachtet wird.
• Benutzerakzeptanztests (oder Benutzerabnahmetests) bestätigen, dass das Produkt alle Akzeptanzkriterien erfüllt und korrekt funktioniert.

Dieser Beitrag vermittelt Ihnen die Grundlagen zum Schreiben von Gherkin-Szenarien, Gherkin-Akzeptanzkriterien und Akzeptanztests in Given-When-Then-Format.

Gherkin’s Given-When-Then Trio für bessere Spezifikationen

Benutzerakzeptanzkriterien sowie Benutzerakzeptanztestfälle / -szenarien können viele verschiedene Formen annehmen; Gherkin Given-When-Then-Szenarien sind jedoch eine der am meisten verbreiteten. Sie folgen der Gherkin-Syntax und drücken die Geschäftslogik in einer einfachen Sprache aus, die jeder in einer Organisation verstehen kann.

Die Gegeben-Wenn-Dann-Struktur gilt als eine der besten, um sicherzustellen, dass eine Spezifikation umfassend und präzise ist. Das Gherkin-Format ermöglicht es uns, klar zu formulieren, was wir wollen und was wir als Ergebnis erwarten.

Das Gegeben-Wenn-Dann Format erklärt

Die Gegeben-Wenn-Dann-Klauseln sind das Herzstück von Gherkin. Sie bieten eine Möglichkeit, einen Satz zu strukturieren, um den logischen Ablauf einer Handlung oder eines Ereignisses zu erklären.

Jeder Textblock wird in freier Form geschrieben, sodass Sie ihn nach Belieben schreiben können. Dies sorgt für eine sehr flexible Struktur – Sie können sie so einfach oder detailliert gestalten, wie Sie möchten – aber auch potenziell verwirrend, da es kein strenges Format gibt.

Sehen Sie sich jede Klausel einzeln an und prüfen Sie, wie sie verwendet wird:

GEGEBEN ( Setup-Daten wie Hardware oder Data)
In der GEGEBEN-Klausel sollten Sie alle Voraussetzungen angeben, die für die erfolgreiche Durchführung des Tests erforderlich sind. Dies umfasst sowohl Hardwarebedingungen als auch Daten, Dateien oder Datensätze, die eine bestimmte Bedingung erfüllen müssen, damit der Test ausgeführt werden kann.

Beispiel: Das System muss über eine verfügbare Netzwerkverbindung verfügen; die Datei „test.txt“ muss existieren und den Text „Hello world!“ enthalten. Wir raten davon ab, offensichtliche Bedingungen wie „Vorausgesetzt, Ihr Computer ist eingeschaltet“ aufzunehmen, aber selbst das ist Ihre Entscheidung.

WENN (Aktion oder Ereignis, das das Szenario auslöst)
Die WENN-Klausel definiert alle Aktionen oder Ereignisse, die das Szenario auslösen. Sie beschreibt die Interaktion zwischen einem Stakeholder und dem System selbst.

Wenn Sie es beispielsweise mit einer Website zu tun haben, listet die WENN-Anweisung die Art der Benutzerinteraktion auf, wie z. B. „gibt einen Wert ein“, „klickt auf eine Schaltfläche“, „füllt ein Formular aus“ usw. Handelt es sich jedoch um eine API, könnte die Stakeholder-Interaktion „antwortet auf einen Aufruf“ lauten. Entscheidend ist, dass WENN den Auslöser für die Ausführung dieses Szenarios definiert.

DANN (definiert das Ergebnis oder den Outcome)
Die DANN-Klausel schließlich definiert die Bedingungen, die bestimmen, ob der Test erfolgreich ist oder nicht. Wenn die Bedingungen in dieser Klausel erfüllt sind, funktioniert die Software ordnungsgemäß, andernfalls schlägt sie fehl. Dieses Ergebnis kann ein berechneter Wert oder ein beliebiges überprüfbares Ergebnis sein.

Gegeben-Wenn-Dann-Beispiele: Das Gherkin-Format in Aktion

Das Gherkin-Format – auch bekannt als das Given-When-Then-Konstrukt – ist eine einfache Methode zur Beschreibung der Interaktionen zwischen einem Benutzer und einer Anwendung. Das Konzept der Szenarien lässt sich am besten anhand eines Beispiels erklären.

Hier ist eine einfache zielorientierte User Story, die wir für ein Schulungsunternehmen erstellt haben:

Um ihre berufliche Entwicklung zu planen, können die Kursteilnehmer anhand ihrer BASE-Ergebnisse sehen, welche Kurse sie noch belegen müssen.

In einem 3-Amigos-Gespräch (englisches Video), erfuhren wir, dass BASE ein Akronym für Business Analysis Skills Evaluation (Bewertung von Geschäftsanalysefähigkeiten) ist — ein Tool zur Erstellung individueller Trainingspläne auf der Grundlage der aktuellen Fähigkeiten eines Teilnehmers.

Wenn Sie über die Tests oder Szenarien nachdenken, die Sie benötigen, um die Umsetzung dieser User Story zu überprüfen, wird klar, dass es ein offensichtliches gibt:

SZENARIO: Kursteilnehmer fordert einen Kursplan an.

Geschäftslogik im Gegeben-Wenn-Dann-Format ausdrücken

Wie bereits erwähnt, beschreibt GEGEBEN die Bedingungen, die erfüllt sein müssen, damit dieses UAT-Szenario die erwarteten Ergebnisse liefert. Mit anderen Worten: Sie definieren die Vorbedingungen für dieses Szenario. Wenn es mehr als eine Vorbedingung gibt, verwenden Sie den Konnektor „UND“.

Damit diese User Story erfolgreich ist, muss der Kursteilnehmer auf der Website angemeldet sein, BASE abgeschlossen haben und mindestens einen unvollendeten Kurs haben.

SZENARIO: Der Kursteilnehmer hat noch nicht beendete Kurse und fordert einen Kursplan an.
GEGEBEN der Kursteilnehmer ist auf der Website angemeldet
UND der Kursteilnehmer hat BASE abgeschlossen
UND der Kursteilnehmer hat nicht abgeschlossene Klassen

Während GEGEBEN die Vorbedingungen beschreibt, löst die WENN-Aktion „Kursteilnehmer fordert Kursplan“ dieses Szenario aus.

Das DANN gibt das Ergebnis an, was bedeutet, dass der angepasste Trainingsplan des Kursteilnehmers  sichtbar ist.

SZENARIO: Der Kursteilnehmer hat noch nicht beendete Kurse und fordert einen Kursplan an.
GEGEBEN der Kursteilnehmer ist auf der Website angemeldet
UND der Kursteilnehmer hat BASE abgeschlossen
UND der Kursteilnehmer hat nicht abgeschlossene Klassen
WENN der Kursteilnehmer den Kursplan anfordert
DANN ist der angepasste Kursplan des Kursteilnehmers sichtbar

Das ist das Grundkonzept von Szenarien, die im Given-When-Then-Gherkin-Format geschrieben sind. Es gibt jedoch noch ein weiteres Schlüsselwort, das sich als nützlich erweisen und Ihnen eine Menge Arbeit ersparen kann – Background.

Background Anweisungen sparen Zeit beim UAT (User Acceptance Testing)

Wenn Sie UAT-Testfälle für Benutzerakzeptanztests im Geben-Wenn-Dann-Format erstellen, denken Sie womöglich, dass dies ein einmaliger Aufwand ist. Sie erstellen die Schritte, schreiben vielleicht sogar einige der Daten als Beispiel, und ehe Sie sich versehen, haben Sie eine nette Sammlung von Testfällen.

Aber dann stellen Sie fest, dass jedes Ihrer UAT-Szenarien die gleichen Setup-Daten (GEGEBEN-Anweisung) verwendet, und Sie müssen alle diese Einstellungen für jeden Testfall neu erstellen.

Diese Wiederholung kann mühsam sein, wenn man sie immer wieder eingeben muss. Zum Glück gibt es eine einfache Lösung und eine große Zeitersparnis: Die HINTERGRUND- oder BACKGROUND-Anweisung in der Gherkin-Syntax ermöglicht es Ihnen, Einrichtungskriterien zu definieren, die für eine Gruppe von Szenarien verwendet werden. Diese Einstellungskriterien können einmal definiert und dann wiederholt von anderen Szenarien verwendet werden.

Alle Gherkin-Anweisungen zwischen der BACKGROUND-Anweisung und dem ersten SZENARIO werden als erster Schritt für jedes SZENARIO in einer Feature-Datei ausgeführt. Das bedeutet 2 Dinge:

• Es darf nur eine BACKGROUND-Anweisung für einen bestimmten Satz von SZENARIOS geben.
• Die BACKGROUND-Anweisung muss allen SZENARIO-Anweisungen zum Testen einer bestimmten User Story vorausgehen.

Um die Verwendung zu veranschaulichen, habe ich ein weiteres Szenario hinzugefügt. Im ersten Szenario hat der Teilnehmer einen Kursplan angefordert und hatte noch nicht beendete Kurse. Das gewünschte Ergebnis in dieser Situation ist die Anzeige des Kursplans.

Im zweiten Szenario fordert der Teilnehmer einen Kursplan an und hat KEINE unvollendeten Kurse. Das gewünschte Ergebnis ist hier, ein Abschlusszertifikat anzubieten.

Unter Verwendung der Background-Anweisung werden die Szenarien wie folgt ausgedrückt:

BACKGROUND
GEGEBEN der Kursteilnehmer ist auf der Website angemeldet
UND der Kursteilnehmer hat BASE abgeschlossen

SZENARIO 1: Der Kursteilnehmer hat noch nicht beendete Kurse und fordert einen Kursplan an
GEGEBEN der Kursteilnehmer hat nicht abgeschlossene Klassen
WENN der Kursteilnehmer den Kursplan anfordert
DANN ist der angepasste Kursplan des Kursteilnehmers sichtbar

SZENARIO 2: Der Kursteilnehmer beantragt einen Kursplan und hat alle erforderlichen Kurse abgeschlossen
GEGEBEN der Kursteilnehmer hat keine unvollendeten Kurse
WENN der Kursteilnehmer den Kursplan anfordert
DANN erhält der Kursteilnehmer ein Abschlusszertifikat

Verwenden Sie, wo immer möglich, Background-Anweisungen, um die Wiederholung gängiger Einrichtungsschritte zu vermeiden. Sie beschleunigen die Aktualisierung allgemeiner Vorbedingungen erheblich. Außerdem sind sie weniger fehleranfällig und sparen Zeit.

Wählen Sie die besten Datenwerte für Ihre Given-When-Then-Szenarien und Testfälle aus

Haben Sie schon einmal die frustrierende Erfahrung gemacht, nicht zu wissen, wie viele Tests ausreichen, um eine User Story oder eine funktionale Anforderung zu verifizieren? Unserer Erfahrung nach können zu viele Testfälle dem Erfolg Ihrer neuesten Version genauso schaden wie zu wenige.

Aber woher wissen Sie, wie viele Abnahmetests ausreichend sind? Sollten Sie jeden möglichen Weg durch das System testen? Wie können Sie sicher sein, dass Ihre Benutzer diese Pfade in der Praxis auch tatsächlich nutzen? Was ist mit unwahrscheinlichen Szenarien? Was ist mit Randfällen? Es ist leicht, sich in den Details des Testens zu verlieren und das Gesamtbild aus den Augen zu verlieren.

Es stellt sich nun die Frage: Wie können Sie die besten Datenwerte für Testfälle oder Szenarien auswählen. Die Antwort lautet Testdaten-Engineering.

Das folgende Video (Englisch mit deutschen Untertiteln) enthält einige Tipps zur Anwendung dieser Technik, die Konzepte wie „Äquivalenzklassen“, „Grenzwerte“ und „wahrscheinliche Fehler“ verwendet, um die Anzahl der zu schreibenden Tests zu begrenzen.

Gegeben-Wenn-Dann-Beispiele für nicht-funktionale Anforderungen

Die meisten Ihrer Szenarien werden die Funktionalität des Produkts oder der Funktion testen, aber nicht-funktionale Akzeptanztests sind genauso wichtig wie funktionale Tests. Wenn Sie die Kundenzufriedenheit sicherstellen wollen, sollten Sie es nicht vernachlässigen, Szenarien zu schreiben, die auch die nichtfunktionalen Anforderungen des Produkts prüfen.

Zur Auffrischung: Nichtfunktionale Anforderungen drücken Bedingungen aus, wie z. B. wie viele, wie oft, wie schnell, wie freundlich, usw. Jede der vier gängigen Arten (Einschränkungen, Leistung, Benutzererfahrung oder Volatilität) sollte getestet werden.

Das Testen nicht-funktionaler Anforderungen kann extrem zeit- und ressourcenintensiv sein. Aus diesem Grund verfügen viele Unternehmen über Spezialisten, deren Hauptaufgabe das Testen von Performance, Sicherheit, User Experience usw. ist.

Wenn jedoch ein NFR für den Erfolg eines Produkts oder einer Funktion wichtig ist, sollten Sie Benutzerakzeptanzkriterien oder UAT-Testfälle definieren, die das Vertrauen schaffen, dass die nichtfunktionale Anforderung erfüllt wurde.

Hier ein Beispiel zur Veranschaulichung:

Als Golfturnierdirektor kann ich die Netto-Stroke-Play-Ergebnisse der Spieler anhand ihrer individuellen USGA-Handicaps anpassen, um ihre Netto-Platzierung im Turnier zu bestimmen.

Die Zerlegung der User Story ergab die folgende nichtfunktionale Anforderung:

Das Handicap eines Spielers muss ein gültiges USGA-Handicap sein.

Es gibt definitiv zwei Szenarien, die für dieses NFR benötigt werden. Eines, in dem der Spieler ein gültiges USGA-Handicap hat, und ein anderes, in dem er keins hat.

Wenn der Spieler zum Beispiel sein USGA-Handicap nachweisen kann, lautet das Szenario:

Szenario: Golfer meldet sich mit einem gültigen USGA-Handicap an
GEGEBEN Golfer hat sich für das Turnier angemeldet
UND Golfer registriert sich am Tag des Turniers für das Spiel
WENN Golf Pro einen Nachweis des USGA-Handicaps verlangt
UND Golfer eine offizielle USGA-Handicap-Karte vorlegt
DANN wird dem Golfer eine Abschlagszeit zugewiesen

Und wenn der Spieler kein offizielles USGA-Handicap hat:

Szenario: Golfer meldet sich ohne gültiges USGA-Handicap an
GEGEBEN Golfer hat sich für das Turnier angemeldet
UND Golfer registriert sich am Tag des Turniers für das Spiel
WENN Golf Pro einen Nachweis des USGA-Handicaps verlangt
UND Golfer hat keine offizielle USGA-Handicap-Karte
DANN verlässt der Golfer das Turnier unter Tränen, weil er nicht spielen darf

Sie könnten mehrere Szenarien für diese nicht-funktionale Anforderung haben. Zum Beispiel: Was passiert, wenn ein Spieler aus Europa teilnimmt? Die Handicaps in Europa werden von der R&A (Royal and Ancient Golf Club, mit Sitz in St. Andrews, Schottland) geregelt. Dies könnte ein weiteres Szenario erfordern, es sei denn, ein R&A-Handicap wird von der USGA als „offizielles“ Handicap akzeptiert.

Gherkin Scenario Outlines erweitern das Geben-Wenn-Dann-Format

Was passiert, wenn Sie ein Wenn-Dann-Szenario mehrmals mit unterschiedlichen Daten testen wollen? Müssen Sie dann für jeden Datensatz ein Szenario erstellen? Das wäre eine große Zeitverschwendung – definitiv nicht LEAN!

Diese Situation ist beim Testen extrem häufig. In der Regel reicht ein einziger Test nicht aus, um zu beweisen, dass die Anwendung so reagiert, wie wir es beabsichtigen. Wir müssen nachweisen, dass die Anwendung unter einer Vielzahl von Umständen, die mit unterschiedlichen Datenwerten dargestellt werden, korrekt reagiert.

Das Umschreiben von Szenarien mit vielen verschiedenen Datenwerten wird schnell mühsam und repetitiv. Scenario Outlines zusammen mit Beispielen reduzieren diesen Aufwand erheblich.

Eine Scenario Outline verwendet ebenfalls die Given-When-Then-Syntax. Sie verwendet jedoch Variablen anstelle von Konstanten, um die Ausführung einer Vielzahl von Tests mit einer einzigen Scenario-Anweisung zu ermöglichen. Es werden keine konstanten Werte wie „Fred“ verwendet, sondern es wird auf „Name“ verwiesen.

Auf die Szenario Outline folgt eine Beispieltabelle, die die verschiedenen Werte enthält, die den einzelnen Variablen zugeordnet sind. Jede Zeile in der Beispieltabelle wird als ein einzelnes Testszenario ausgeführt.

Um die Gherkin-Syntax zusammenzufassen,

• Ein SZENARIO hat Konstanten und KEINE Variablen.
• Mit einer BACKGROUND Anweisung können Sie Redundanzen in SZENARIEN minimieren.
• Ein Szenario OUTLINE hat Variablen, die über eine BEISPIELTABELLE (EXAMPLE TABLE ) gefüllt werden.
• Jede Zeile in der BEISPIELTABELLE wird als ein SZENARIO ausgeführt.
• Eine SZENARIO Outline kann eine unbegrenzte Anzahl von BEISPIELEN haben.

Zum Abschluss

Gherkin Given-When-Then ist eine unkomplizierte und einfache Sprache, die es nicht-technischen Personen ermöglicht, klar und präzise zu beschreiben, was sie von einem Produkt oder einer Funktion erwarten.

Die Gherkin-Syntax eignet sich perfekt für Benutzerakzeptanzkriterien und für die Beschreibung von Benutzerakzeptanztests (UAT). Mit Gherkin können Sie nicht nur klar mit den Beteiligten kommunizieren, sondern auch Anforderungen in ausführbare Softwarespezifikationen übersetzen. Das bedeutet, dass diese Sprache Ihnen dabei hilft, umfassendere und genauere Spezifikationen für Ihr Projekt zu erstellen und diese Spezifikationen während des Entwicklungsprozesses besser zu kommunizieren.

Mit Gherkin als Grundlage können Sie sich mit allen an der Entwicklung Ihres Produkts oder Ihrer Funktion beteiligten Parteien besser abstimmen, da alle Beteiligten eine klare Terminologie verwenden können.

Welche Erfahrungen haben Sie mit der Verwendung von Gherkin zur Definition von Akzeptanzkriterien und -szenarien für Akzeptanztests gemacht? Welches Format wird in ihrer Firma angewendet um Benutzertests zu erstellen? 

Bitte unten einen Kommentar hinterlassen!