Gegeben-Wenn-Dann Akzeptanzkriterien erklärt
Format: Gegeben-Wenn-Dann-Kriterien definieren ein klares, testbares Softwareverhalten für ein gemeinsames Verständnis im Team.
Struktur: Jedes Szenario in diesem Format enthält den Kontext, die Nutzeraktion und das erwartete Ergebnis in klarer Sprache.
Best Practices: Konzentrieren Sie sich auf Einfachheit, Zusammenarbeit und Details, um die Klarheit der Akzeptanzkriterien zu verbessern.
Häufige Fehler: Vermeiden Sie das Zusammenpressen mehrerer Szenarien, technische Details und das Ignorieren von Randfällen.
Given-When-Then (GWT)-Akzeptanzkriterien bieten eine einfache, testbare Möglichkeit, zu beschreiben, wie Software sich verhalten soll, sodass Entwickler, Tester und Stakeholder ein gemeinsames Verständnis haben. Wenn Akzeptanzkriterien unklar sind, vergeuden Teams Zeit mit Diskussionen über Anforderungen, entwickeln die falsche Lösung und entdecken Lücken erst spät in der Entwicklung.
In diesem Leitfaden erkläre ich das Given-When-Then-Format, zeige reale Beispiele aus gängigen Szenarien, vergleiche es mit anderen Ansätzen für Akzeptanzkriterien und teile bewährte Praktiken, mit denen agile Teams klarere und effektivere User Stories schreiben.
Was sind Given-When-Then-Akzeptanzkriterien?
Given-When-Then ist eine dreiteilige Vorlage zum Schreiben von Akzeptanzkriterien für User Stories. Jedes Szenario beschreibt eine Facette des erwarteten Verhaltens in verständlicher Sprache, die Entwickler, Tester und Stakeholder gleichermaßen lesen können.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
So funktioniert der Aufbau:
- Given beschreibt, was bereits wahr sein muss, bevor der Endnutzer etwas tut.
- When leitet die Aktion ein. Es ist das, was der Benutzer tut oder das Ereignis, das das System auslöst.
- Then beschreibt das Ergebnis. Es ist das Resultat, das beweist, dass das System korrekt reagiert hat.
Wie schreibt man Given-When-Then-Akzeptanzkriterien?
Wie man jede Klausel so formuliert, dass sie während der Entwicklung und beim Softwaretest standhält.
Given: Kontext und Voraussetzungen festlegen
Die Given-Klausel beschreibt, was bereits erfüllt sein muss. Dazu gehören Systemzustand, Benutzerrolle, Datenlage und Umgebungsbedingungen. Gute "Given"-Aussagen sind spezifisch. Vermeiden Sie Formulierungen wie „Angenommen, der Benutzer ist eingeloggt“, wenn das Szenario von der Rolle abhängt. Schreiben Sie stattdessen: „Angenommen, ein registrierter Kunde mit gültigem Abonnement befindet sich auf der Kontoeinstellungsseite.“
Einige Richtlinien zur Formulierung der Given-Klausel:
- Nennen Sie die Benutzerrolle oder Persona, wenn sie wichtig ist.
- Nennen Sie Systembedingungen wie Feature Flags, Datenstatus oder Konnektivität.
- Kombinieren Sie mehrere Voraussetzungen mit „Und“, anstatt sie in eine einzige Klausel zu zwängen.
When: Die Aktion oder den Auslöser bestimmen
Die When-Klausel beschreibt die Aktion oder das Ereignis, das das zu testende Verhalten auslöst. Sie sollte eine Benutzeraktion oder ein Systemereignis beschreiben, nicht eine Folge davon. Verwenden Sie die aktive Formulierung. Schreiben Sie zum Beispiel: „Wenn der Kunde auf 'Coupon anwenden' klickt“ statt „Wenn der Coupon-Button angeklickt wird“. Das beseitigt Unklarheiten, wer die Aktion ausführt.
Halten Sie diese Klausel prägnant. Wenn Sie mehr als eine When-Aussage benötigen, beschreiben Sie wahrscheinlich zwei verschiedene Szenarien. Teilen Sie diese auf.
Then: Das erwartete Ergebnis spezifizieren
Die Then-Klausel beschreibt, was der Nutzer beobachten sollte oder was das System nach der Aktion tun soll. Beschreiben Sie beobachtbare Ergebnisse. „Dann wird das Dashboard geladen“ ist schwach. „Dann zeigt das System das Dashboard des Kunden innerhalb von zwei Sekunden an“ ist testbar. Fügen Sie Spezifika wie Fehlermeldungen, Umleitungsziele, Datenänderungen, E-Mail-Benachrichtigungen oder UI-Statusänderungen ein.
Verwenden Sie Und, um mehrere Ergebnisse zu verketten, wenn eine einzelne Aktion mehr als ein beobachtbares Resultat produziert. Zum Beispiel: „Dann wird die Auftragsbestätigungsseite angezeigt“ und „der Kunde erhält innerhalb von 60 Sekunden eine Bestätigungs-E-Mail.“
Beispiele für Given-When-Then
Hier sind einige Beispiele für Given-When-Then-Akzeptanzkriterien aus verschiedenen Bereichen.
Benutzer-Login
Szenario 1: Erfolgreiche Anmeldung mit gültigen Zugangsdaten
Angenommen ein registrierter Benutzer befindet sich auf der Login-Seite Wenn der Benutzer eine gültige E-Mail und das richtige Passwort eingibt und auf „Einloggen“ klickt Dann leitet das System den Benutzer zum persönlichen Dashboard weiter
Die Given-Klausel ist hier bewusst schlank gehalten, da das Szenario nicht vom Abonnement-Typ oder Kontostatus abhängt. Beachten Sie die zusammengesetzte When-Klausel: Das Eingeben der Zugangsdaten und das Klicken auf einen Button ist eine logische Handlung (das Absenden eines Login-Formulars), weshalb ich sie zusammenhalte, statt für jede Kleinigkeit ein separates Szenario zu schreiben.
Szenario 2: Fehlgeschlagene Anmeldung mit ungültigen Zugangsdaten
Gegeben ein registrierter Benutzer befindet sich auf der Login-Seite Wenn der Benutzer eine gültige E-Mail-Adresse und ein falsches Passwort eingibt und auf „Anmelden“ klickt Dann zeigt das System die Meldung „Ungültige E-Mail oder Passwort“ an Und der Benutzer bleibt auf der Login-Seite
Die Dann-Klausel spezifiziert den genauen Wortlaut der Fehlermeldung. Die zweite Und-Klausel ist wichtig, weil sie bestätigt, dass der Benutzer nicht versehentlich woandershin weitergeleitet wird.
Warenkorb und Checkout
Szenario 1: Einen Artikel zum Warenkorb hinzufügen
Gegeben ein Kunde betrachtet die Produktdetailseite eines vorrätigen Artikels Wenn der Kunde auf „In den Warenkorb“ klickt Dann aktualisiert sich das Warenkorb-Symbol und zeigt einen Artikel an Und eine Bestätigungsmeldung zeigt „Artikel zum Warenkorb hinzugefügt“
Die Gegeben-Klausel enthält „vorrätig“, weil sich das Verhalten bei ausverkauften Artikeln unterscheidet. Das ist ein separates Szenario.
Szenario 2: Einen gültigen Rabattcode anwenden
Gegeben ein Kunde hat zwei Artikel im Warenkorb mit einem Gesamtwert von $80.00 Wenn der Kunde den Rabattcode „SAVE20“ eingibt und auf „Anwenden“ klickt Dann wendet das System einen 20% Rabatt an Und aktualisiert sich der Warenkorbbetrag auf $64.00
Die konkreten Dollarbeträge verhindern Missverständnisse. Ein solches Rabattszenario kann helfen, einen Rundungsfehler in der Produktion aufzudecken, bei dem ein prozentualer Rabatt auf eine ungerade Summe einen Preis mit drei Nachkommastellen ergab. Die Genauigkeit in der Gegeben-Klausel ($80.00) und der Dann-Klausel ($64.00) macht das Szenario wertvoll.
Passwort-Wiederherstellung
Szenario 1: Passwort-Zurücksetzung mit registrierter E-Mail anfordern
Gegeben ein Benutzer befindet sich auf der Login-Seite Wenn der Benutzer auf „Passwort vergessen“ klickt, eine registrierte E-Mail-Adresse angibt und auf „Absenden“ klickt Dann zeigt das System „Ein Zurücksetzungslink wurde an Ihre E-Mail-Adresse gesendet“ an Und sendet das System innerhalb von 60 Sekunden eine E-Mail zum Zurücksetzen des Passworts
Das zusammengesetzte Wenn stellt einen einzigen logischen Ablauf dar: Die Anforderung einer Zurücksetzung. Die Zeitbegrenzung von 60 Sekunden in der Dann-Klausel ist entscheidend. Ohne sie würde eine Zurücksetzungs-E-Mail, die nach 20 Minuten eintrifft, technisch ebenfalls „bestehen“. Zeitgebundene Resultate gehören zu den am häufigsten ausgelassenen Details.
Szenario 2: Verwendung eines abgelaufenen Zurücksetzungslinks
Gegeben ein Benutzer hat vor mehr als 24 Stunden eine E-Mail zum Zurücksetzen des Passworts erhalten Wenn der Benutzer auf den Link in der E-Mail klickt Dann zeigt das System an: „Dieser Link ist abgelaufen. Bitte fordern Sie einen neuen Zurücksetzungslink an.“
Die Gegeben-Klausel enthält eine Zeitbedingung, die eine Diskussion darüber erzwingt, wie lang das Ablaufintervall sein soll.
Formularvalidierung
Szenario 1: Senden eines Formulars mit fehlenden Pflichtfeldern
Gegeben ein Benutzer befindet sich im Registrierungsformular Wenn der Benutzer das Feld „E-Mail“ leer lässt und auf „Absenden“ klickt Dann zeigt das System eine Inline-Fehlermeldung „E-Mail ist erforderlich“ unter dem E-Mail-Feld an Und das Formular wird nicht abgeschickt
Die Dann-Klausel gibt an, wo der Fehler erscheint („unter dem E-Mail-Feld“), nicht nur, dass er erscheint.
Szenario 2: Überschreiten der Zeichenbegrenzung in einem Textfeld
Gegeben ein Benutzer füllt das Feld „Biografie“ (maximal 500 Zeichen) aus Wenn der Benutzer 501 Zeichen eingibt Dann verhindert das System weitere Eingaben Und erscheint die Nachricht „Maximal 500 Zeichen erlaubt“
GWT vs. Checklisten vs. Anwendungsfälle
Hier sind einige andere Arten von Akzeptanzkriterien und wann Sie welche verwenden würden:
| Aspekt | Given-When-Then | Regelorientierte Checkliste | Anwendungsfall |
|---|---|---|---|
| Struktur | Given, When, Then | Aufzählung von Regeln | Nummerierte Schritte mit Abläufen |
| Beste Anwendung | Verhaltensszenarien, BDD | Geschäftsregeln, UI-Spezifikationen | Komplexe Multi-Flow-Features |
| Stärken | Testbar, automatisierbar, kontextreich | Schnell zu schreiben, leicht zu überblicken | Gründlich, deckt Sonderfälle ab |
| Einschränkungen | Umfangreich bei einfachen Änderungen | Kein Szenariofluss, schwer zu automatisieren | Umfangreich, aufwendig zu pflegen |
| Zielgruppe | Entwicklung, QA, Produkt | Produkt, Design, Stakeholder | Externe Teams, Compliance |
| Geltungsbereich | Einzelnes Verhalten | Gesamtes Feature | Gesamtes Feature |
| Detailgrad | Drei Abschnitte | Flexibel | Vorbedingungen, Nachbedingungen, Auslöser und nummerierte Schritte |
Ich habe festgestellt, dass Anwendungsfälle am besten geeignet sind, wenn Sie ein System für regulatorische Anforderungen dokumentieren oder an einen externen Dienstleister übergeben. Für die alltägliche Sprint-Arbeit ist Given-When-Then schlanker und schneller.
Best Practices für Given-When-Then
Hier finden Sie einige Best Practices, um GWT effektiv einzusetzen:
- Vermeiden Sie vage oder mehrdeutige Formulierungen: Statt „Dann lädt die Seite schnell“, schreiben Sie „Dann lädt die Suchergebnisseite innerhalb von zwei Sekunden.“ Ersetzen Sie Adjektive wie „angemessen“ oder „relevant“ durch messbare Werte. Wenn Sie es nicht testen können, formulieren Sie es neu.
- Halten Sie Szenarien einfach und fokussiert: Befolgen Sie die Regel: Ein Szenario pro Verhalten. Jedes Szenario sollte genau eine Sache testen. Mehrere Aktionen oder Ergebnisse in einem Szenario führen zu schwer nachvollziehbaren und wartbaren Testfällen. Wenn ein Szenario mehr als zwei "und"-Aussagen unter "Dann" enthält, fragen Sie sich, ob Sie wirklich nur ein Verhalten testen.
- Führen Sie eine Three-Amigos-Session durch: Eine Three-Amigos-Session ist ein kurzes, gezieltes Treffen, bei dem eine Produktperson (Product Owner oder Business Analyst), ein Entwickler und ein Tester gemeinsam die kommenden Stories vor dem Sprint durchgehen. Dabei werden die GWT-Kriterien gemeinsam erstellt oder verfeinert, was Nacharbeit vermeidet.
- Halten Sie Terminologie und Stil konsistent: Legen Sie Standardbegriffe fest und verwenden Sie diese für jede Story. Wenn Sie in einem Szenario „Kunde“ und im nächsten „Benutzer" schreiben, entsteht Verwirrung. Legen Sie bei Bedarf ein kleines Glossar an. Verwenden Sie einen einheitlichen Satzbau in Ihren Formulierungen.
Fünf häufige Anti-Patterns
Hier sind einige häufige Fehler, die Sie beim Schreiben von Given-When-Then-Akzeptanzkriterien vermeiden sollten:
- Implementierungsdetails statt Verhalten beschreiben: Szenarien wie „Angenommen, der API-Aufruf gibt den Statuscode 200 zurück“ beschreiben technische Implementierungen und kein Nutzerverhalten. Formulieren Sie stattdessen aus Sicht des Nutzers: „Angenommen, der Produktkatalog wurde auf der Startseite geladen.“ Technische Details gehören in den Testautomatisierungscode.
- Mehrere Szenarien in eines quetschen: Ein Szenario, das Login, Navigation und Checkout in einem Block testet, ist ein Integrationstest, kein Akzeptanzkriterium. Teilen Sie jedes Verhalten in ein eigenes Szenario auf. So erhalten Sie klarere Ergebnisse und können leichter Fehler beheben.
- Negative und Randfälle auslassen: Agile Entwicklungsteams schreiben oft nur den „Happy Path“ und vergessen, was passiert, wenn etwas schiefgeht. Stellen Sie sich bei jedem erfolgreichen Szenario die Frage: Was passiert bei ungültigen Eingaben? Was, wenn das Netzwerk ausfällt? Was, wenn Daten fehlen? Schreiben Sie mindestens ein Negativszenario pro Story, um Probleme vor der Produktion zu erkennen.
- GWT als einzig zulässiges Format betrachten: Verwenden Sie GWT für das Nutzerverhalten und Checklisten für alles andere. Wenn Sie jede Story in Given-When-Then pressen – einschließlich Button-Farbänderungen, Textänderungen und Infrastrukturkonfigurationen – erhalten Sie teils absurde Ergebnisse (z. B. „Angenommen, die Startseite existiert, Wenn der Nutzer sie aufruft, Dann ist die Header-Schriftgröße 16px.“).
- Szenarien isoliert schreiben: Schreiben Sie GWT-Kriterien nicht allein. Der Wert des Formats entsteht durch das Gespräch, das es anregt. Wenn Ihre Szenarien nicht mindestens von zwei Disziplinen besprochen werden, bevor die Softwareentwicklung beginnt, nutzen Sie GWT nur als Dokumentationsformat, obwohl seine wahre Stärke im kollaborativen Einsatz liegt.
Wie geht es weiter?
Klare Given-When-Then-Akzeptanzkriterien sind nur ein Teil, um erfolgreiche Projekte abzuliefern. Bauen Sie darauf auf mit einer kostenlosen DPM-Mitgliedschaft und erhalten Sie Zugriff auf praktische Vorlagen, Expertenressourcen und bewährte Frameworks, die helfen, klar definierte Anforderungen in einen reibungsloseren Ablauf und bessere Ergebnisse zu verwandeln.
