Akzeptanzkriterien als Prüfskript
Jede Lieferung bekommt ein Skript, das ihre Akzeptanzkriterien am fertigen Ergebnis nachmisst und laut scheitert, statt sie in Prosa zu behaupten.
Jede Lieferung bekommt ein Skript, das ihre Akzeptanzkriterien am fertigen Ergebnis nachmisst und laut scheitert, statt sie in Prosa zu behaupten.
„Funktioniert" ist kein Kriterium. Ein Datensatz kann vollständig aussehen und falsch sein, ein Export sauber wirken und eine Spalte verloren haben. Wer nur hinschaut, sieht das, was er erwartet – und findet den Fehler erst Wochen später im Betrieb, wenn überhaupt.
Besonders tückisch sind Fehler, die nichts kaputt machen: eine Zeile, die still aus einer Prüfung fällt, ein Feld, das leer bleibt, weil eine Bedingung zu eng war. Nichts stürzt ab, kein Log meldet etwas.
Akzeptanzkriterien werden so formuliert, dass ein Programm sie am fertigen Ergebnis nachrechnen kann – nicht am Code, der es erzeugt hat. Nicht „die Tabelle ist vollständig", sondern „das Blatt enthält mindestens 1.200 Zeilen, die Kombination aus Name und Postleitzahl ist eindeutig, und jede Zeile trägt eine Quellenangabe".
Das Skript läuft nach jedem Durchlauf, meldet jeden Verstoß mit Fallbeispiel und beendet sich mit Fehlercode. Kein „meistens grün".
Im Kanuvereine-Datensatz hat genau dieses Skript zwei Fehler abgefangen, die niemandem aufgefallen wären.
Der erste: Eine Prüfung hatte eine veraltete Datei bewertet, weil die aktuelle noch in Excel geöffnet war und nicht überschrieben werden konnte. Das Ergebnis war grün – für den falschen Stand.
Der zweite: Nach einer Korrektur trugen vierzehn Zeilen ein Gewässer, galten aber gleichzeitig als „ohne Bootshaus" – ein Widerspruch, den das Skript sofort benannte. Ursache war derselbe Denkfehler an einer zweiten, übersehenen Stelle.