Akzeptanzkriterien sind die Bedingungen, die ein Stück Arbeit erfüllen muss, bevor irgendjemand es als fertig bezeichnet. Sie werden geschrieben, bevor die Arbeit beginnt, von der Person, die sie beauftragt, und abgestimmt mit denen, die sie bauen und testen werden.

Ihre Aufgabe ist es, einen Streit nach vorne zu verlegen. Ohne sie wird “ist das fertig?” nach der Arbeit entschieden, von dem, der am lautesten überzeugt ist. Mit ihnen war es vorher entschieden, von Leuten, die ruhig waren.

Was sie nicht sind

Keine Beschreibung der Funktion. “Der Nutzer kann den Bericht filtern” ist eine Zusammenfassung. Ein Kriterium sagt, was wahr sein muss: welche Filter, was passiert, wenn keiner zutrifft, welcher Zustand nach einem Neuladen gilt.

Kein Entwurf. Kriterien beschreiben Ergebnisse, keine Layouts. “Ein Dropdown oben rechts” entscheidet die Lösung und nimmt sie demjenigen weg, der am besten in der Lage ist, sie zu wählen.

Keine Testfälle. Ein Kriterium ist eine Bedingung; ein Testfall ist ein Vorgehen, um eine davon zu prüfen. An einem einzelnen Kriterium hängen meist mehrere Testfälle, und sie werden später geschrieben, von jemandem, der nicht dieselbe Person sein muss.

Die zwei Formate, die verwendet werden

Eine Checkliste ist das schlichtere der beiden, und für die meiste Arbeit reicht sie.

Fertig, wenn:
- Eine angemeldete Person sieht nur ihre eigenen Bestellungen
- Eine Bestellung ohne Positionen erscheint trotzdem, mit einer Summe von 0,00
- Die Liste lädt für ein Konto mit 10.000 Bestellungen innerhalb von zwei Sekunden
- Die Sortierung nach Datum bleibt über die Seitenumbrüche hinweg erhalten

Gegeben, wenn, dann ist förmlicher, und der zusätzliche Aufwand lohnt sich, wenn das Verhalten vom Zustand abhängt.

Gegeben eine Kundin mit einer abgelaufenen Karte
Wenn sie das Kassenformular abschickt
Dann wird die Zahlung abgelehnt
Und die Kartenfelder behalten die eingegebenen Werte
Und die Meldung sagt, welches Feld zu korrigieren ist

Der Wert steckt im Gegeben. Die meisten Missverständnisse leben im Ausgangszustand - ein Testkonto, ein abgelaufenes Token, eine leere Liste - und nicht in der Handlung, und das Format zwingt jemanden, ihn zu benennen.

Keines der Formate ist besser. Nehmen Sie standardmäßig die Checkliste und greifen Sie zu Gegeben-wenn-dann, wo sich dieselbe Handlung je nach Situation unterschiedlich verhalten muss.

Was ein gutes Kriterium von einem schlechten trennt

Die Probe ist, ob zwei Leute darüber streiten könnten, ob es erfüllt ist.

Schwach
Die Seite soll schnell laden und relevante Ergebnisse zeigen
Besser
Die erste Ergebnisseite erscheint für ein Konto mit 10.000 Bestellungen innerhalb von zwei Sekunden und zeigt nur Bestellungen, die diesem Konto gehören

Vier Gewohnheiten bringen die meisten schwachen hervor:

  • Adjektive statt Schwellen. Schnell, intuitiv, robust, benutzerfreundlich. Keines lässt sich prüfen; über alle lässt sich streiten.
  • Nur der glückliche Pfad. Kriterien, die beschreiben, was passiert, wenn alles funktioniert, überlassen jedes Scheitern dem Urteil von irgendjemandem um vier Uhr nachmittags am Tag des Releases.
  • Lösungen. “Einen Bestätigungsdialog hinzufügen” statt “die Nutzerin kann eine Rechnung nicht ohne Bestätigung löschen”.
  • Alles auf einmal. Eine Story mit neunzehn Kriterien sind mehrere Storys, und sie wird vierzehn Tage lang halbfertig sein.

Wer sie schreibt, und wann

Wer die Arbeit beauftragt, entwirft sie, und sie werden abgestimmt, bevor jemand anfängt. Das ist der Teil, den Teams auslassen, und das Auslassen ist es, was aus einer Zweitagesaufgabe eine Woche voller Rückfragen macht.

Es muss nicht schwer sein. Ein Entwickler, der den Entwurf liest und fragt “was soll passieren, wenn sie noch keine Bestellungen haben”, ist der ganze Prozess bei der Arbeit: die Frage ist jetzt billig und nach dem Code teuer.

Schreiben Sie sie dort auf, wo die Arbeit liegt, nicht in eine Chatnachricht. Kriterien, die nur in jemandes Erinnerung an eine Besprechung existieren, erzeugen genau den Streit, den sie verhindern sollten.

Wo sie am Ende zählen

Zwei Stellen, und sie sind der Grund, warum sich die Mühe lohnt.

Die Abnahme. Die Leute, die Abnahmetests durchführen, brauchen etwas, wogegen sie abnehmen können. Ohne Kriterien wird daraus eine Umfrage über Meinungen zu Software, für die jemand bereits bezahlt hat.

Die Fehlertriage. Der zäheste Streit in der Softwareentwicklung ist der, ob etwas ein Defekt oder eine Änderungsanforderung ist, und entschieden wird er durch das, was vereinbart war. Ein Defekt ist Verhalten, das einem Kriterium widerspricht; alles andere ist eine neue Anforderung, so vernünftig sie auch sein mag. Teams ohne geschriebene Kriterien führen diesen Streit einmal pro Release, für immer.

Das ist auch der Grund, warum die Meldung eines Defekts sagen sollte, was erwartet wurde, und nicht nur, was passiert ist - es ist derselbe Satz wie das Kriterium, dem sie widerspricht.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen können.

Erweiterung holen

Der Leitfaden für Fehlerberichte deckt den Rest dessen ab, was so eine Meldung braucht, und seine Vorlage hat eine Zeile für das erwartete Verhalten.

Die Kurzfassung

Bedingungen, vor der Arbeit geschrieben, abgestimmt zwischen denen, die sie beauftragt haben, und denen, die sie bauen, genau genug, dass zwei Leute nicht darüber streiten können, ob sie erfüllt sind. Eine Checkliste reicht meistens; Gegeben-wenn-dann, wenn der Ausgangszustand über das Ergebnis entscheidet. Decken Sie ab, was passiert, wenn Dinge scheitern, nicht nur, wenn sie funktionieren.