Was macht ein gutes Akzeptanzkriterium aus, und wie schreibst du sie?

Ein gutes Kriterium ist testbar, spezifisch und frei von Implementierungsdetails. Jemand sollte es lesen und bestanden oder nicht bestanden sagen können, ohne irgendetwas zu interpretieren. Deck die negativen Pfade genauso bewusst ab wie den glücklichen: ungültige Eingabe, fehlende Berechtigung, Timeout, leeres Ergebnis. Wenn du nicht beschreiben kannst, wie du es testen würdest, ist es noch kein Kriterium, sondern eine Hoffnung.

Mein Test ist, ob jemand es lesen und bestanden oder nicht bestanden ankreuzen könnte, ohne mich zu fragen. Bleibt Interpretationsspielraum, ist es nicht fertig. Ich vermeide also Wörter wie angemessen, benutzerfreundlich und schnell und ersetze sie durch etwas, das man wirklich prüfen kann. Die andere Hälfte der Arbeit sind die negativen Pfade, aus denen die meisten Defekte kommen. Was passiert bei ungültiger Eingabe, was sieht ein Nutzer ohne Berechtigung, was passiert, wenn der nachgelagerte Service ins Timeout läuft, wie sieht ein leeres Ergebnis aus. Das sind Entscheidungen, die jemand treffen muss, und wenn ich sie nicht mit dem Business treffe, trifft sie ein Entwickler im Schnellverfahren an einem Donnerstagnachmittag. Ich gehe die Kriterien außerdem mit einem Entwickler und einem Tester durch, bevor die Arbeit gezogen wird. Das dauert zwanzig Minuten und findet immer zwei oder drei Dinge, die ich mehrdeutig gelassen hatte.