Wie Sie Akzeptanzkriterien für eine kleine Web-App schreiben

Wofür Akzeptanzkriterien da sind

Akzeptanzkriterien legen fest, was erfüllt sein muss, damit eine Funktion als fertig gilt. Sie beenden den Streit am Ende eines Projekts, weil die Vereinbarung zu Beginn schriftlich festgehalten wurde. Außerdem geben sie dem Entwickler etwas Konkretes, worauf er hinarbeiten kann, statt einer allgemeinen Idee wie „Die Buchung sollte einfach sein“.

Das dreiteilige Muster

Die Cucumber-Dokumentation zu Gherkin beschreibt eine Struktur, die für ausführbare Spezifikationen verwendet wird. Given-Schritte beschreiben den Ausgangskontext des Systems. When-Schritte beschreiben ein Ereignis. Then-Schritte beschreiben ein erwartetes Ergebnis. Sie brauchen keine Software, um diese Idee zu nutzen. Das Schreiben in dieser Reihenfolge erzwingt schlicht Klarheit.

Die Cucumber-Referenz sagt außerdem, dass der Zweck von Given-Schritten darin besteht, das System in einen bekannten Zustand zu versetzen, bevor der Nutzer damit zu interagieren beginnt, und rät davon ab, darin von Nutzerinteraktion zu sprechen. Wenn Ihr Given wie eine Handlung klingt, gehört es vermutlich in das When.

Ein Verhalten nach dem anderen

Beschränken Sie jedes Kriterium auf ein einzelnes Verhalten. „Given a customer has chosen a free slot, when they submit the form, then they see a confirmation with the date and time“ ist prüfbar. „Das Formular funktioniert gut und sieht gut aus“ ist es nicht. Wenn ein Satz zwischen zwei Ergebnissen das Wort „und“ braucht, sollten Sie erwägen, ihn aufzuteilen.

Konkrete Werte verwenden

Ersetzen Sie vage Wörter durch Werte, die sich testen lassen: ein bestimmtes Datum, ein bestimmter Betrag, eine genaue Meldung. Die Gherkin-Referenz zeigt, wie sich ähnliche Beispiele in einer Szenariovorlage (Scenario Outline) mit einer Wertetabelle zusammenfassen lassen. Einfach gesagt: Wenn dieselbe Regel für mehrere Fälle gilt, schreiben Sie die Regel einmal und listen darunter die Werte auf.

Ablehnungen und Randfälle abdecken

Fügen Sie für jede Funktion mindestens ein Kriterium dafür hinzu, was nicht passieren soll: ein bereits vergebener Termin, eine fehlende E-Mail-Adresse, eine Person ohne Berechtigung. Viele Streitigkeiten am Ende eines Projekts betreffen einen Randfall, den niemand aufgeschrieben hat.

• Das erwartete Ergebnis bei ungültiger Eingabe
• Was ein Nutzer ohne Berechtigung sieht
• Was bei einer leeren Liste oder einem Erstnutzer passiert
• Wie die Seite auf einem schmalen Smartphone-Bildschirm aussieht
• Welche Schritte nur mit der Tastatur weiterhin funktionieren müssen

Ein hypothetisches Beispiel

Stellen Sie sich eine kleine App vor, in der Kunden einen Reparaturbesuch anfragen. Ein Kriterium lautet: Given ein Kunde ist angemeldet und hat keine offene Anfrage, when er eine Anfrage mit Beschreibung und Wunschtag absendet, then erscheint die Anfrage in seiner Liste mit dem Status „Eingegangen“. Ein zweites lautet: Given die Beschreibung ist leer, when er absendet, then bleibt das Formular offen und zeigt neben dem Beschreibungsfeld eine Meldung. Ein drittes lautet: Given ein angemeldeter Kunde, when er die Adresse der Anfrage eines anderen Kunden öffnet, then sieht er eine Seite mit verweigertem Zugriff. Jedes lässt sich in einer Minute prüfen. Dieses Beispiel ist hypothetisch.

Vereinbaren und beibehalten

Gehen Sie die Kriterien vor dem Bau mit der Person durch, die die Arbeit abnehmen wird. Wenn sich etwas ändert, ändern Sie auch die Kriterien und notieren Sie das Datum. Gehen Sie sie bei der Übergabe gemeinsam einzeln durch. Dass jedes Kriterium erfüllt ist, beweist nicht, dass die App perfekt ist, aber es macht die Vereinbarung sichtbar und die Übergabe entspannt.