Abnahmekriterien, Definition of Done, Exit-Kriterien: drei Begriffe, drei Fragen

Es gibt eine Szene, die in fast jedem Projekt vorkommt. Kurz vor dem Release sitzen fünf Leute zusammen, und jemand fragt: „Sind wir fertig?“ Der Entwickler sagt ja, der Code ist zusammengeführt. Die Fachabteilung sagt nein, so war das nicht gemeint. Der Tester sagt, drei Fälle sind noch offen, aber vielleicht sind sie nicht wichtig. Und der Projektleiter versucht, aus drei verschiedenen Antworten eine Entscheidung zu machen.

Der Grund für diese Szene ist fast nie Nachlässigkeit. Er ist begrifflich. Alle drei antworten korrekt, nur auf verschiedene Fragen. Und niemand hat vorher aufgeschrieben, welche Frage die entscheidende ist.

Drei Begriffe, drei Ebenen

Die Bezugsgröße ist der Schlüssel. Ein Abnahmekriterium gilt für eine Anforderung und ist inhaltlich. Eine Definition of Done gilt für alle Arbeitsergebnisse gleichermaßen und ist handwerklich. Ein Exit-Kriterium gilt für eine Phase und ist statistisch. Wer diese drei in einem Dokument vermischt, bekommt eine Liste, die für jeden Einzelfall entweder zu grob oder zu speziell ist.

Abnahmekriterien: der fachliche Teil

Abnahmekriterien beschreiben, woran erkennbar ist, dass eine Anforderung oder User Story die fachlichen Erwartungen erfüllt. Die fachliche Verantwortung für den gewünschten Nutzen liegt bei der Fachseite. Gute Abnahmekriterien entstehen jedoch häufig gemeinsam mit Entwicklung und Test, damit sie eindeutig, vollständig und prüfbar sind. In kollaborativen Ansätzen wie ATDD werden noch fehlende Abnahmekriterien ausdrücklich gemeinsam analysiert, diskutiert und formuliert.

Vier Eigenschaften machen den Unterschied zwischen einem brauchbaren und einem dekorativen Kriterium:

• Prüfbar. Man muss sich ein Vorgehen vorstellen können, mit dem sich das Kriterium eindeutig als erfüllt oder nicht erfüllt feststellen lässt. „Die Oberfläche ist intuitiv“ ist kein Kriterium. „Ein Nutzer ohne Vorkenntnis schließt die Bestellung in höchstens vier Schritten ab“ ist eines.
• Binär. Kein „weitgehend“, kein „im Wesentlichen“. Ein Kriterium, das teilweise erfüllt sein kann, verschiebt die Entscheidung nur in die Diskussion.
• Mit Zahl, wo eine Zahl gemeint ist. „Performant“ heißt für jeden etwas anderes. „Antwortzeit unter zwei Sekunden bei fünfzig gleichzeitigen Nutzern“ heißt für alle dasselbe.
• Mit Negativfall. Die meisten Kriterien beschreiben den Gutfall. Der Schaden entsteht im Fehlerfall. Was passiert bei ungültiger Eingabe, bei Zeitüberschreitung, bei doppeltem Absenden? Ein Kriterienkatalog ohne Negativfälle ist die Hälfte der Anforderung.

Der ISTQB-Lehrplan ordnet die zugehörige Teststufe klar ein: „Acceptance testing focuses on validation and on demonstrating readiness for deployment, which means that the system fulfills the user's business needs.“ Es geht bei der Abnahme also nicht darum, ob etwas technisch funktioniert, sondern ob es den fachlichen Bedarf erfüllt. Das ist eine andere Prüfung als der Systemtest, und sie braucht andere Kriterien.

Definition of Done: der handwerkliche Teil

Die Definition of Done stammt aus Scrum und ist dort präzise gefasst. Der Scrum Guide 2020 sagt: „The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.“ Sie beschreibt also einen Zustand, keinen Inhalt. Ob die richtige Funktion gebaut wurde, sagt sie nicht. Sie sagt, ob das Gebaute in dem Zustand ist, in dem man es ausliefern könnte.

Zwei weitere Sätze aus dem Scrum Guide werden in der Praxis regelmäßig übersehen. Der erste betrifft die Konsequenz: „If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.“ Das ist keine Empfehlung, sondern eine harte Regel. Eine Definition of Done ohne diese Konsequenz ist eine Wunschliste.

Der zweite betrifft die Zuständigkeit: „If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.“ Der Unternehmensstandard ist die Untergrenze, nicht die Obergrenze. Ein Team darf strenger sein, nicht lockerer.

Was typischerweise hineingehört: Code-Review erfolgt, statische Analyse ohne kritische Befunde, Unit-Tests grün, Test Cases zur Story geschrieben und ausgeführt, keine offenen Fehler der Schwere hoch oder kritisch, Dokumentation aktualisiert, Änderung im Testsystem lauffähig. Was nicht hineingehört, sind fachliche Aussagen zu einer bestimmten Story. Die stehen in den Abnahmekriterien.

Exit-Kriterien: der steuernde Teil

Exit-Kriterien beantworten die Frage, ob eine Testphase beendet werden darf. Sie stehen im Testkonzept, gehören also zum Testmanagement, und sie sind der Grund, warum ein Testkonzept vor dem Testen entstehen muss. Der ISTQB-Lehrplan behandelt sie zusammen mit den Entry-Kriterien im Abschnitt zur Testplanung.

Typische Exit-Kriterien sind Abdeckungsgrade, Fehlerzahlen nach Schwere, offene Risiken und die Vollständigkeit der Nachweise. Entscheidend ist nicht die Auswahl, sondern der Zeitpunkt: Wer die Schwelle erst festlegt, nachdem die Zahlen bekannt sind, legt keine Schwelle fest, sondern beschreibt das Ergebnis. Der menschliche Reflex, eine Grenze dorthin zu schieben, wo man ohnehin gelandet ist, wirkt zuverlässig und unbewusst.

Das Gegenstück ist die Definition of Ready: die Bedingungen, unter denen eine Anforderung überhaupt in die Umsetzung darf. Ohne sie beginnt das Testteam mit Anforderungen zu arbeiten, die noch keine prüfbaren Kriterien haben, und schreibt Test Cases gegen Vermutungen.

Wie die drei zusammenspielen

Die Kette ist einfach, wenn die Begriffe sauber getrennt sind:

• Die Abnahmekriterien einer Anforderung liefern die Vorlage für die Test Cases. Ein Kriterium ohne zugehörigen Test Case ist ungeprüft, ein Test Case ohne zugehöriges Kriterium ist unbegründet. Diese Zuordnung ist genau das, was eine Requirements-Traceability-Matrix sichtbar macht.
• Die Definition of Done stellt sicher, dass jedes Inkrement überhaupt in einem prüfbaren Zustand ankommt. Ohne sie testet man gegen bewegliche Ziele und misst vor allem die eigene Wartezeit.
• Die Exit-Kriterien entscheiden über den Abschluss der Phase und speisen den Freigabe-Nachweis. Sie sind die einzige der drei Ebenen, auf der über Restrisiken gesprochen wird.

Die vier häufigsten Fehler

• Die Definition of Done ohne Konsequenz. Eine Checkliste, die im Zweifel übergangen wird, kostet Zeit und erzeugt keine Qualität. Entweder gilt sie, oder man streicht sie.
• Abnahmekriterien, die die Anforderung wiederholen. Steht in der Story „Der Nutzer kann sich anmelden“ und im Kriterium „Der Nutzer kann sich anmelden“, ist nichts gewonnen. Das Kriterium muss den Nachweis beschreiben, nicht den Wunsch.
• Fertig ohne Nachweis. „Getestet“ ist kein Zustand, sondern eine Behauptung, solange kein Ergebnis dokumentiert ist. Der Unterschied zeigt sich erst im Audit oder im Schadensfall, und dann zuverlässig.
• Nachträglich angepasste Schwellen. Sobald eine Grenze verschoben wird, weil man sie sonst reißt, war sie nie eine Grenze. Wenn es gute Gründe für die Anpassung gibt, gehören sie dokumentiert und von derselben Instanz entschieden, die die Freigabe verantwortet.

Wer was macht

Abnahmekriterien verantwortet die Fachseite, die Definition of Done das Entwicklungsteam, die Exit-Kriterien das Testmanagement. Qelivia unterstützt an allen drei Stellen unterschiedlich: Wir prüfen Abnahmekriterien auf Prüfbarkeit und ergänzen fehlende Negativfälle, wir bringen eine belastbare Definition of Done als Vorlage ein, und wir formulieren die Exit-Kriterien im Testkonzept so, dass die Freigabeentscheidung am Ende auf Zahlen steht. Die Tests führt Ihr Team durch, wir liefern die Struktur, das Review und den Nachweis.

Fazit

„Sind wir fertig?“ ist keine Frage, sondern drei. Ob das Richtige gebaut wurde, beantworten die Abnahmekriterien. Ob es sauber gebaut wurde, beantwortet die Definition of Done. Ob genug geprüft wurde, beantworten die Exit-Kriterien. Wer die drei trennt und vorher aufschreibt, braucht für die Freigabe kein Meeting, sondern einen Blick auf drei Listen.