In der Landschaft der Softwareentwicklung ist die Kluft zwischen dem, was Stakeholder sich vorstellen, und dem, was Entwickler bauen, oft die Quelle erheblicher Spannungen. Mehrdeutigkeit in Anforderungen führt zu Nacharbeit, verzögerten Releases und frustrierten Teams. Um diese Kluft zu überbrücken, benötigen Teams eine gemeinsame Sprache, die präzise, lesbar und ausführbar ist. Eine der effektivsten Techniken, um diese Klarheit zu erreichen, ist dieGiven When ThenSyntax. Dieser Ansatz verwandelt vage User Stories in konkrete Spezifikationen des Verhaltens.
Wenn sie korrekt angewendet wird, dient diese Methode nicht nur als Schreibübung, sondern wird zu einem Vertrag zwischen dem Geschäft, dem Design-Team und der Entwicklung. Sie stellt sicher, dass jedes gelieferte Feature mit dem vorgesehenen Wert übereinstimmt. Dieser Leitfaden untersucht die Mechanik, Vorteile und bewährten Praktiken für die effektive Verwendung von Given When Then zur Spezifikation des Verhaltens von User Stories.
🧠 Verständnis der Kernstruktur
Das Given When Then-Muster ist eine grundlegende Komponente des Behavior-Driven-Development (BDD). Es strukturiert Akzeptanzkriterien so, dass sie natürliche Sprache nachahmen, wodurch sie für nicht-technische Stakeholder zugänglich sind, gleichzeitig aber ausreichend detailliert für automatisiertes Testen bleiben. Jeder Teil des Musters erfüllt eine eindeutige Funktion bei der Definition des Lebenszyklus einer Szenario.
- Gegeben: Legt den ursprünglichen Kontext oder Zustand fest. Es schafft die Grundlage, indem es die Voraussetzungen beschreibt, die vor der Aktion erfüllt sein müssen.
- Wenn: Beschreibt das spezifische Ereignis oder die Aktion, die das Verhalten auslöst. Dies ist die Eingabe oder der Reiz.
- Dann: Definiert das beobachtbare Ergebnis oder die Auswirkung. Es bestätigt, dass das System nach der Aktion wie erwartet reagiert.
Durch die Trennung von Kontext, Aktion und Ergebnis können Teams Variablen isolieren und genau verstehen, welcher Teil des Systems für ein bestimmtes Verhalten verantwortlich ist. Diese Modularität verringert die Komplexität und erleichtert das Debugging erheblich.
📝 Aufteilung der Komponenten
🏗️ Der „Gegeben“-Kontext
Der Gegeben-Schritt wird oft übersehen, ist aber entscheidend für die richtige Umgebung. Er sollte nicht die Aktion selbst beschreiben, sondern den Zustand des Systems. Ein gut formulierter Gegeben-Schritt beantwortet die Frage: „Was muss vor Beginn wahr sein?“
Berücksichtigen Sie die Feinheiten beim Schreiben dieses Abschnitts:
- Zustand gegenüber Daten:Unterscheiden Sie zwischen dem Zustand der Anwendung (z. B. ein Benutzer ist angemeldet) und den vorhandenen Daten (z. B. der Benutzer hat ein Guthaben von 100 $).
- Voraussetzungen:Listen Sie alle notwendigen Voraussetzungen auf. Wenn eine Zahlung aufgrund unzureichender Mittel fehlschlägt, muss der Gegeben-Schritt sicherstellen, dass das Guthaben tatsächlich überprüft wird.
- Lesbarkeit:Halten Sie es deklarativ. Vermeiden Sie imperativen Sprachgebrauch wie „Klicken Sie auf die Schaltfläche.“ Stattdessen verwenden Sie „Der Benutzer befindet sich auf dem Dashboard.“
Wenn der Gegeben-Schritt mehrdeutig ist, schlagen Tests unvorhersehbar fehl. Wenn der Systemzustand nicht klar definiert ist, könnte die Automatisierung gegen eine andere Umgebung laufen als beabsichtigt, was zu falsch negativen Ergebnissen führt.
🚀 Der „Wenn“-Auslöser
Der Wenn-Schritt stellt die Interaktion dar. Es ist der Moment, in dem der Benutzer oder das System eine Änderung auslöst. Dies sollte eine einzelne, atomare Aktion sein. Wenn Sie mehrere Aktionen in einen Wenn-Schritt zusammenfassen, wird es schwierig, festzustellen, welcher Teil des Ablaufs einen Fehler verursacht hat.
Wichtige Überlegungen für den Wenn-Abschnitt sind:
- Einzelverantwortlichkeit:Konzentrieren Sie sich auf ein Ereignis pro Szenario. Wenn Sie eine Abfolge von Ereignissen testen müssen, überlegen Sie, sie in separate Szenarien aufzuteilen oder Szenario-Ausführungen zu verwenden.
- Benutzerabsicht:Formulieren Sie die Aktion aus der Perspektive des Benutzers oder der Systemgrenze. „Der Benutzer sendet das Formular“ ist besser als „Der Absende-Button wird geklickt.“
- Zeitpunkt:Vermeiden Sie vage Begriffe wie „bald“ oder „später“. Seien Sie genau bezüglich des Auslöseereignisses.
📝 Das „Dann“-Ergebnis
Der Dann-Schritt ist die Überprüfungsmechanismus. Er bestätigt, dass das System korrekt auf den Wenn-Schritt reagiert hat. Hier wird der Wertvorschlag überprüft.
Wirksame Dann-Schritte sollten:
- Beobachtbar sein:Überprüfen Sie etwas, was sichtbar oder messbar ist. Prüfen Sie Benutzeroberflächenelemente, Datenbankdatensätze oder API-Antworten.
- Vermeiden Sie Implementierungsdetails:Konzentrieren Sie sich auf das Ergebnis, nicht auf die interne Logik. „Die Bestätigungsmitteilung erscheint“ ist besser als „Die Datenbank-ID wird erhöht.“
- Abdecken von Erfolg und Fehler:Stellen Sie sicher, dass Sie angeben, was geschieht, wenn die Aktion fehlschlägt. „Dann wird eine Fehlermeldung angezeigt“ ist ebenso wichtig wie „Dann wird die Bestellung aufgegeben.“
📊 Verbesserung der Klarheit durch strukturierte Daten
Um die Lesbarkeit zu verbessern und Wiederholungen zu reduzieren, verwenden Teams oft Tabellen in ihren Spezifikationen. Dies ist besonders nützlich, wenn mehrere Varianten des gleichen Verhaltens mit unterschiedlichen Daten eingaben getestet werden.
| Szenariotyp | Schwerpunkt | Beispiel |
|---|---|---|
| Glücklicher Pfad | Standarderfolgsablauf | Gegeben gültige Anmeldeinformationen, wenn der Login versucht wird, dann wird das Dashboard angezeigt. |
| Randfall | Grenzbedingungen | Gegeben ein Passwort mit 8 Zeichen, wenn eine Zurücksetzung angefordert wird, dann wird das Passwort akzeptiert. |
| Negativer Pfad | Fehlerbehandlung | Gegeben eine abgelaufene Sitzung, wenn auf Zugriff angefragt wird, dann erfolgt eine Umleitung zur Anmeldung. |
Durch diese Struktur können Stakeholder die Anforderungen schnell überfliegen und den Umfang der Abdeckung verstehen, ohne dichte Absätze von Text lesen zu müssen.
🚫 Häufige Fallen, die vermieden werden sollten
Selbst mit einem soliden Rahmen begehen Teams oft Fehler, die die Wirksamkeit der Spezifikation untergraben. Die frühzeitige Erkennung dieser Fallen sichert die Haltbarkeit der Dokumentation.
❌ Vermischung von Aspekten
Ein häufiger Fehler besteht darin, Geschäftsregeln mit technischen Beschränkungen in derselben Stufe zu kombinieren. Zum Beispiel vermischt der Satz „Gegeben ist, dass die Datenbank verbunden ist“ Infrastruktur mit Verhalten. Das System sollte voraussetzen, dass die Verbindung auf einer tieferen Ebene behandelt wird. Konzentrieren Sie sich auf den geschäftlichen Kontext.
❌ Uneindeutige Verben
Wörter wie „verarbeiten“, „behandeln“ oder „verwalten“ sind zu allgemein. Sie definieren nicht das Ergebnis. Statt „Das System verarbeitet die Bestellung“ zu sagen, verwenden Sie stattdessen „Die Bestätigungs-E-Mail für die Bestellung wird versendet“. Präzision beseitigt Interpretationsfehler.
❌ Zu viele Szenarien
Während Detailfreude gut ist, führt zu große Spezifizierung zu Wartungsaufwand. Wenn ein Szenario zwanzig Given-Schritte hat, versucht es wahrscheinlich zu viel zu tun. Zerlegen Sie es in kleinere, wiederverwendbare Kontextblöcke.
❌ Technische Kopplung
Schreiben Sie keine Szenarien, die von spezifischen Implementierungsdetails wie Klassennamen oder Datenbankschemata abhängen. Diese ändern sich häufig und brechen Tests unnötigerweise. Konzentrieren Sie sich auf das beobachtbare Verhalten.
👥 Dynamik der Zusammenarbeit
Die Stärke von Gegeben Wenn Dann liegt in der Zusammenarbeit, die sie fördert. Es ist nicht nur ein Dokumentationsformat, sondern ein Werkzeug zur Unterstützung der Teamausrichtung.
- Product Owner: Sie definieren die „Dann“-Ergebnisse basierend auf geschäftlichem Wert. Sie stellen sicher, dass das Verhalten die Nutzerbedürfnisse erfüllt.
- Entwickler: Sie klären den „Gegeben“-Kontext, um Vorbedingungen und Abhängigkeiten zu verstehen.
- QA-Spezialisten: Sie validieren die „Wenn“-Aktionen, um sicherzustellen, dass das System korrekt reagiert und Randfälle abgedeckt sind.
Diese gemeinsame Verständigung verringert die Abhängigkeit von Dokumentation, die in einer Isolation liegt. Wenn die Spezifikation in einem gemeinsamen Format verfasst wird, trägt jeder zur Qualität der Anforderung bei.
🔁 Von der Spezifikation zur Automatisierung
Ein Hauptvorteil dieser Syntax ist ihre direkte Abbildung auf automatisierte Testframeworks. Obwohl die spezifischen Werkzeuge variieren, bleibt die logische Struktur konstant.
Wenn ein Szenario klar formuliert ist, kann es mit minimalem Aufwand in ausführbaren Code übersetzt werden:
- Schrittdefinitionen:Jeder Gegeben-, Wenn- oder Dann-Ausdruck kann einer Funktion im Test-Set zugeordnet werden.
- Wiederverwendbarkeit:Häufige Kontexte (wie „Benutzer ist angemeldet“) können einmal definiert und in mehreren Szenarien wiederverwendet werden.
- Regressionssicherheit:Wenn die Anwendung sich weiterentwickelt, wirken diese Szenarien als Sicherheitsnetz und stellen sicher, dass neuer Code bestehendes Verhalten nicht stört.
Diese Integration schafft eine einzige Quelle der Wahrheit. Die Akzeptanzkriterien sind die Tests, und die Tests sind die Akzeptanzkriterien. Diese Ausrichtung stellt sicher, dass genau das getestet wird, was vereinbart wurde.
💎 Praktische Beispiele
Um den Unterschied zwischen einer Standardanforderung und einer Verhaltensspezifikation zu veranschaulichen, betrachten wir ein konkretes Feature: eine Anfrage zur Passwortrücksetzung.
❌ Uneindeutige Spezifikation
„Der Benutzer sollte in der Lage sein, sein Passwort zurückzusetzen, falls er es vergisst. Das System sollte eine E-Mail senden.“
Dies lässt zu viel Interpretationsspielraum. Was geschieht, wenn die E-Mail-Adresse ungültig ist? Was, wenn der Benutzer nicht existiert? Die Zeitpunkt der E-Mail-Sendung ist nicht definiert.
✅ Gegeben Wenn Dann Spezifikation
Szenario: Anfordern einer Passwortzurücksetzung
Gegebender Benutzer verfügt über ein Konto, das mit der E-Mail-Adresse „[email protected]“ registriert ist
Wennsie das Zurücksetzungsformular mit dieser E-Mail-Adresse absenden
Danneine Bestätigungs-Nachricht wird auf dem Bildschirm angezeigt
Undein Zurücksetzungslink wird an „[email protected]“ gesendet
Szenario: Zurücksetzen mit unbekannter E-Mail-Adresse
Gegebenes gibt kein Konto, das mit „[email protected]“ verknüpft ist
Wennsie das Zurücksetzungsformular absenden
Danneine generische Erfolgsmeldung wird angezeigt
Undkeine E-Mail wird an die bereitgestellte Adresse gesendet
Diese Beispiele zeigen, wie Sicherheit und Benutzerfreundlichkeit explizit berücksichtigt werden. Das zweite Szenario schützt die Privatsphäre des Benutzers, indem es nicht offenbart, ob ein Konto existiert, was eine entscheidende Sicherheitsüberlegung ist.
🛡️ Datengetriebene Szenarien
Häufig gilt ein einzelnes Verhalten für mehrere Datensätze. Die Erstellung separater Szenarien für jede Variation kann sich wiederholend erweisen. Die Lösung besteht darin, Szenario-Ausschreibungen zu verwenden.
Diese Struktur ermöglicht es Ihnen, den Ablauf einmal zu definieren und ihn mit verschiedenen Datenpunkten zu füllen.
| Eingabebetrag | Erwarteter Kontostand | Status |
|---|---|---|
| $50 | $150 | Erfolg |
| $-10 | $100 | Fehler |
| $1000 | $1000 | Limit erreicht |
Durch die Definition des Ablaufs mit Platzhaltern behalten Sie die Lesbarkeit bei, während Sie eine umfassende Abdeckung gewährleisten. Dieser Ansatz reduziert Duplikate und erleichtert die Aktualisierung. Wenn sich der Ablauf ändert, aktualisieren Sie die Vorlage anstatt von fünfzig einzelnen Szenarien.
📏 Wartung und Evolution
Spezifikationen sind keine statischen Artefakte. Sie müssen sich entwickeln, je weiter sich das Produkt weiterentwickelt. Regelmäßige Überprüfungen sind notwendig, um sicherzustellen, dass die Given-When-Then-Schritte weiterhin korrekt sind.
Best Practices für die Wartung umfassen:
- Schritte zur Refaktorisierung: Wenn ein Schritt zu komplex wird, refaktorisieren Sie ihn in kleinere, sinnvolle Einheiten.
- Ablauf: Entfernen Sie Szenarien, die die aktuelle Geschäftslogik nicht mehr widerspiegeln.
- Versionsverwaltung: Verfolgen Sie Änderungen an Szenarien, um zu verstehen, wie sich die Anforderungen im Laufe der Zeit verändert haben.
Die Investition von Zeit in die Wartung dieser Spezifikationen zahlt sich in Form reduzierter Fehleranzahlen und schnellerer Einarbeitung neuer Teammitglieder aus. Neue Entwickler können die Szenarien lesen, um das Systemverhalten zu verstehen, ohne durch den Code zu wühlen.
💡 Letzte Überlegungen zur Spezifikation
Klare Spezifikationen zu verfassen ist eine Disziplin, die Übung und Sorgfalt erfordert. Das Given-When-Then-Muster bietet einen robusten Rahmen für diese Disziplin. Es zwingt Teams, die Auswirkungen ihrer Features zu überdenken, bevor Code geschrieben wird.
Durch die Fokussierung auf Kontext, Aktion und Ergebnis erstellen Sie ein lebendiges Dokument, das Entwicklung und Test treibt. Es bringt das Team um eine gemeinsame Definition des Fertigstellungsstatus zusammen. Diese Ausrichtung ist die Grundlage für die Lieferung hochwertiger Software.
Denken Sie daran, dass das Ziel die Kommunikation ist. Wenn ein Stakeholder das Szenario nicht verstehen kann, ist es noch nicht bereit. Verwenden Sie diese Struktur, um Dialog zu fördern, Erwartungen zu klären und Software zu entwickeln, die die Bedürfnisse der Nutzer wirklich erfüllt.
