Abnahmekriterien je Arbeitspaket, die sich in Tests überführen lassen

Ziel

„Fertig" für ein einzelnes Arbeitspaket entscheidbar machen, bevor die Arbeit beginnt, sodass Entwicklerin oder Entwickler, Reviewer und die anfragende Person sich auf dieselben Beispiele einigen.

Voraussetzungen

Ein Arbeitspaket mit festgehaltenem Zweck (wer was warum braucht), Zugang zu der Person, die Fachfragen beantworten kann, sowie ein Ort, an dem die Kriterien beim Arbeitspaket liegen.

Schritte

1. Die Regel in einem Satz formulieren, dann die Beispiele. Die Gherkin-Referenz beschreibt diese Form: ein Ausgangskontext (Given), ein Ereignis (When) und ein erwartetes Ergebnis (Then), und empfiehlt 3 bis 5 Schritte je Beispiel, damit es als Spezifikation lesbar bleibt.
2. Den Hauptfall, jede Grenze und die Fehlerpfade abdecken. Eine Kriterienmenge für „Uploads auf 10 MB begrenzen" umfasst mindestens: genau 10 MB werden akzeptiert, 10 MB plus ein Byte werden mit der angegebenen Meldung abgelehnt, und die Ablehnung hinterlässt keine unvollständige Datei.
3. Konkrete Werte verwenden, keine Adjektive: "the balance shows £430" statt "the balance is correct". Gherkins eigene Beispiele stellen "there is money in my account" gegen "my account has a balance of £430".
4. Nutzerinteraktion aus dem Given heraushalten und Implementierungsdetails aus allem heraushalten: Kriterien beschreiben Verhalten, das an der Grenze sichtbar ist, die Nutzerin, Nutzer oder Client sehen.
5. Jedes Kriterium lesen und fragen: Könnte eine Testperson, die den Code nie gesehen hat, allein aus diesem Text über Bestehen oder Nichtbestehen entscheiden? Falls nicht, umschreiben.
6. Markieren, was für dieses Arbeitspaket bewusst ausserhalb des Umfangs liegt, sodass „du hast X vergessen" durch das Arbeitspaket beantwortet wird, nicht durch Erinnerung.
7. Vor der Umsetzung schlägt die Entwicklerin oder der Entwickler jedes fehlende Beispiel vor; die anfragende Person bestätigt. Hier gefundene Meinungsverschiedenheiten sind günstiger als im Review.
8. Die Beispiele dort in automatisierte Tests überführen, wo die Grenze es erlaubt (API, Fachlogik), und dort in eine manuelle Checkliste, wo nicht (visuelles Layout). Den Test oder die Checkliste vom Arbeitspaket aus verlinken.

Erwartetes Ergebnis

Review und Abnahme werden zu einem Abgleich mit aufgelisteten Beispielen; Scope Creep zeigt sich als neues Beispiel, das ausgehandelt statt einfach angenommen werden muss.

Grenzen und Prüfbasis

Beispiele können nicht alles aufzählen; nichtfunktionale Anforderungen (Latenz, Barrierefreiheit) brauchen ein messbares Ziel statt eines Szenarios. Gherkin-Tooling ist optional; die Disziplin liegt in den Beispielen, nicht im Ausführer. Methode aus der zitierten Referenz und gängiger Praxis zusammengestellt; es wird keine Wirkung auf die Fehlerrate behauptet.