Akzeptanzkriterien sind die Bedingungen, die eine User Story erfüllen muss, damit die Stakeholder sie abnehmen, und der ISTQB-Lehrplan behandelt sie als Testbedingungen. Sie legen fest, was ein Testfall später prüft, noch bevor Code existiert. Der Lehrplan nennt zwei Formate: szenarioorientiert mit Gegeben/Wenn/Dann und regelorientiert als Checkliste oder Tabelle. Die Beispiele unten stammen aus dem Zahlungsverkehr einer Bank: ein Überweisungslimit mit Grenzwerten und eine Vier-Augen-Freigabe für Firmenzahlungen. Beide enthalten die negativen Fälle, die für eine Bank das höchste Risiko tragen.

Kurz gefasst: Akzeptanzkriterien beschreiben, wann eine User Story abgenommen wird, und gelten nach ISTQB CTFL 4.5.2 als Testbedingungen. Schreiben Sie sie szenarioorientiert (Gegeben/Wenn/Dann) oder regelorientiert (Tabelle) und immer mit positiven und negativen Fällen. KI kann daraus Tests entwerfen: In einer Industriestudie waren 60 % der generierten Testabläufe ohne Änderung nutzbar (Ferreira et al., 2025).

Abbildung 1: Im 3-C-Modell sind die Akzeptanzkriterien die Confirmation einer User Story.

Was sind Akzeptanzkriterien?

Akzeptanzkriterien sind Bedingungen, die ein Arbeitsergebnis erfüllen muss, damit die Stakeholder es akzeptieren; in agilen Teams hängen sie an einer User Story. Das offizielle ISTQB-Glossar definiert sie als „Die Kriterien, die ein Arbeitsergebnis erfüllen muss, um durch die Stakeholder akzeptiert zu werden.“ Als Synonym führt es den Begriff Abnahmekriterien.

Der deutsche Lehrplan Certified Tester Foundation Level 4.0.2 zieht daraus eine praktische Folgerung: „Aus dieser Perspektive können Akzeptanzkriterien als die Testbedingungen betrachtet werden, die durch die Tests ausgeführt werden sollten.“ (GTB, CTFL-Lehrplan 4.0.2, 2025). Eine Testbedingung (test condition) ist laut Glossar ein „testbarer Aspekt einer Komponente oder eines Systems“. Die Kriterien sagen, was getestet wird. Der Testfall legt fest, wie.

Im Lehrplan stehen sie im Modell der 3 C von Ron Jeffries: Card, Conversation, Confirmation. Die Confirmation sind die Kriterien (ISTQB CTFL 4.0.1, 2024). Bill Wake liefert mit INVEST den Praxistest dazu: Wer eine Story aufschreibt, verspricht, das Gewünschte gut genug zu kennen, um einen Test dafür zu schreiben (Wake, 2003).

Welche zwei Formate für Akzeptanzkriterien gibt es?

Der ISTQB-Lehrplan nennt zwei Formate: „Szenarioorientiert (z. B. das Gegeben/Wenn/Dann-Format …)“ und „Regelorientiert“, etwa als Verifizierungsliste oder als Tabelle mit Input-Output-Zuordnung (GTB, 2025). Beide sind zulässig, solange die Kriterien klar definiert und eindeutig sind.

Abbildung 2: Szenarioorientiert für Abläufe, regelorientiert für Regeln mit vielen Kombinationen.

Szenarioorientiert: Überweisung mit Tageslimit

Die User Story lautet: „Als Privatkundin möchte ich im E-Banking Überweisungen bis zu meinem Tageslimit freigeben, damit ich Rechnungen ohne Anruf bei der Bank bezahlen kann.“

Zeile 2 prüft den Grenzwert, Zeile 3 den ersten ungültigen Betrag direkt darüber. Schlüsselwörter, Scenario Outlines und Beispieltabellen erklärt der Artikel zur Gherkin-Syntax. Wie Fachbereich, Entwicklung und Test mit diesem Format zusammenarbeiten, beschreibt der Beitrag zu BDD-Testing.

Regelorientiert: Vier-Augen-Freigabe für Firmenzahlungen

Die User Story lautet: „Als Compliance-Verantwortliche möchte ich, dass Firmenzahlungen ab CHF 50.000 eine zweite Freigabe brauchen, damit niemand große Beträge allein auslöst.“

Das Regelformat passt, wenn eine Geschäftsregel viele Kombinationen aus Betrag, Rolle und Person hat. Drei der fünf Regeln beschreiben, was das System verhindern muss. Für eine Bank sind das die Zeilen mit dem höchsten Risiko, und sie ergeben später die Negativtests.

Wie schreiben Sie gute Akzeptanzkriterien?

Gute Akzeptanzkriterien sind eindeutig, prüfbar und beschreiben positive und negative Szenarien; der ISTQB-Lehrplan verlangt in Abschnitt 4.5.2 klar definierte, eindeutige Kriterien, die positive und negative Szenarien beschreiben (GTB, CTFL-Lehrplan 4.0.2, 2025). Unklare Anforderungen kosten Projekte: In der NaPiRE-Erhebung 2014/15 unter 228 Unternehmen aus 10 Ländern waren unvollständige oder versteckte Anforderungen das am häufigsten genannte Problem (109 Unternehmen, 48 %). 43 davon sahen darin eine Ursache für gescheiterte Projekte (NaPiRE-Studie, 2017).

Prüfliste für jedes Kriterium:

• Beobachtbares Ergebnis: Jedes Kriterium endet mit etwas, das ein Test sehen kann, zum Beispiel eine Meldung, ein Status oder ein Kontostand.

• Konkrete Werte: „CHF 8.000“ statt „hohe Beträge“, „innerhalb von 2 Sekunden“ statt „schnell“.

• Ein Verhalten pro Kriterium: Zwei Regeln in einem Satz ergeben zwei Kriterien.

• Negative Fälle: ungültige Beträge, fehlende Rechte, gesperrte Konten und Werte knapp neben der Grenze.

• Fachliche Sprache: Beschreiben Sie, was fachlich passiert („die Zahlung wird abgelehnt“). Klickpfade und Button-Farben gehören in den Testfall.

• Überschaubare Menge: Der QS-Baukasten des Bundesverwaltungsamts nennt als Faustregel 4 bis 8 Kriterien pro Story (BVA QS-Baukasten, 2024).

Die Reihenfolge beim Testen gibt der Lehrplan vor: „Nachdem die positiven Testfälle abgeschlossen sind, sollte das Team Negativtests durchführen.“ (GTB, 2025). Das klappt nur, wenn die Kriterien die negativen Fälle vorher benennen. Wie Sie ungültige Eingaben systematisch finden, zeigt der Artikel zum Negativtest. Bei abnahmetestgetriebener Entwicklung (ATDD) entstehen die Testfälle vor der Umsetzung, und die Abnahmetests werden, so der Lehrplan, „zu ausführbaren Anforderungen“.

Wie unterscheiden sich Akzeptanzkriterien und Definition of Done?

Akzeptanzkriterien gelten für genau eine User Story und beschreiben ihr fachliches Verhalten; die Definition of Done gilt für jedes Increment und beschreibt Qualitätsmaßnahmen, die immer erfüllt sein müssen. Der Scrum Guide nennt die DoD „eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt“ (Scrum Guide 2020, 2020).

Die Begriffe Akzeptanzkriterien und User Story kommen im Scrum Guide 2020 nicht vor. Beide stammen aus dem Umfeld von Extreme Programming, etwa aus dem 3-C-Modell von Ron Jeffries (Jeffries, 2001), und sind heute im ISTQB-Lehrplan beschrieben. Viele Teams nutzen sie in Scrum als ergänzende Praxis.

Ein Punkt wie „Code-Review erledigt“ gehört in die DoD und muss nicht in jeder Story stehen. Wie Teams eine DoD aufbauen und prüfen, steht im Artikel zur Definition of Done.

Wie wird aus einem Kriterium ein automatisierter Test?

Aus Akzeptanzkriterien entsteht ein automatisierter Test in sieben Schritten, von der Story über Testfälle und einen freigegebenen Testablauf bis zur Verknüpfung in Jira und Xray. Die Reihenfolge folgt der ISTQB-Kette aus Testanalyse (Testbedingungen), Testentwurf (Testfälle) und Testrealisierung (Testskripte) (ISTQB CTFL 4.0.1, 2024).

Abbildung 3: In sieben Schritten vom Kriterium zum freigegebenen, nachverfolgbaren Test.

1. Story schreiben: Rolle, Ziel und Nutzen im Format „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“.

2. Kriterien im Workshop abstimmen: Product Owner, Entwicklung und Test einigen sich auf positive und negative Kriterien. Der Lehrplan nennt das Spezifikations-Workshop.

3. Format wählen: Gegeben/Wenn/Dann für Abläufe, eine Tabelle für Regeln mit vielen Kombinationen.

4. Testfälle ableiten: Aus jedem Kriterium entstehen ein oder mehrere Testfälle mit Vorbedingungen, Testdaten und erwarteten Ergebnissen.

5. Automatisieren: Ein Werkzeug oder ein Engineer setzt die Testfälle in ausführbare Tests um.

6. Jeden Schritt prüfen und freigeben: Ein Mensch vergleicht den Entwurf mit den Kriterien, bevor er läuft.

7. Ausführen und verknüpfen: Die Pipeline startet die Tests. Die Ergebnisse landen am Jira-Ticket, wo die Abdeckung der Story nachvollziehbar ist.

Zu Schritt 4: Mike Cohn nennt die Kriterien abstrakter als Testfälle; ein einzelnes Kriterium könne zu vielen Tests führen (Mountain Goat Software, 2026).

Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Der AI Recorder entwirft aus einem Jira-Ticket, einer User Story oder einem Testfall in Klartext einen ausführbaren Test-Workflow. Jeder KI-generierte Schritt muss vom Team freigegeben werden, bevor er läuft.

Für Schritt 7 synchronisiert die Jira- und Xray-Anbindung von Autemos Testfälle und Ausführungen in beide Richtungen. Laut Xray-Dokumentation zählen Cucumber-Tests, die mit einer Jira-Story verknüpft sind, zu deren Anforderungsabdeckung (Xray Traceability Report, o. J.). Welche Kriterien einer Story getestet und bestanden sind, steht damit direkt am Ticket.

Gehören mehrere Kriterien zu einem durchgehenden Geschäftsablauf wie Erfassen, Freigeben und Buchen einer Zahlung, lohnt sich ein eigenes Testszenario. Die formale Abnahme durch den Fachbereich behandelt der Beitrag zum Abnahmetest.

Wie gut erzeugt KI Tests aus schriftlichen Kriterien?

KI erzeugt aus Akzeptanzkriterien brauchbare Testentwürfe, die ein Mensch prüfen muss: In einer Industriestudie mit GPT-4 Turbo waren 60 % der generierten Testabläufe ohne Änderung nutzbar (Ferreira et al., IEEE/ACM AST, 2025). Insgesamt bewerteten die Beteiligten 92 % der Testabläufe als hilfreich und die erzeugten Gherkin-Szenarien in 95 % der Fälle.

Abbildung 4: 60 % der KI-generierten Testabläufe waren ohne Änderung nutzbar (Ferreira et al., 2025).

Die Studie stammt aus einem einzigen Unternehmen. Die Autoren sehen den Nutzen von Sprachmodellen an zwei Bedingungen geknüpft: passende Werkzeuge und menschliche Aufsicht.

Ein Preprint der RMIT University mit 500 User Stories zeigt, wovon die Qualität abhängt. Alle drei getesteten Sprachmodelle lieferten schlechtere Tests, wenn sie nur die User Story bekamen. Mit detaillierten Anforderungen blieb die Qualität stabil (Rathnayake et al., Preprint, 2026).

Für Teams heißt das: Die Kriterien begrenzen, was eine KI daraus machen kann. Steht der negative Fall nicht in den Kriterien, hat das Modell keine Vorlage dafür. Der Freigabeschritt ist die Stelle, an der ein Mensch jeden erzeugten Schritt mit den Kriterien vergleicht.

Welche Fehler machen Teams beim Schreiben der Kriterien?

Typische Fehler bei Akzeptanzkriterien sind vage Begriffe, fehlende Negativfälle und Klickanweisungen, die keine fachliche Regel beschreiben. Die folgenden Muster lassen sich im Refinement schnell erkennen:

• Nur der Happy Path ist beschrieben; Ablehnungen, Rechte und Grenzwerte fehlen.

• Begriffe wie „schnell“, „benutzerfreundlich“ oder „korrekt“ stehen ohne Messwert da.

• DoD-Punkte wie „Code-Review erledigt“ wiederholen sich in jeder Story.

• Die Kriterien entstehen erst nach der Umsetzung und beschreiben den Ist-Zustand.

• Eine Story hat 15 Kriterien und ließe sich in drei Stories teilen.

• Die Kriterien ändern sich im Sprint, die verknüpften Tests bleiben alt.

Werkzeuge finden schwache Anforderungstexte nur teilweise. Femmer et al. erkannten sogenannte Requirements Smells automatisch mit einer durchschnittlichen Präzision von 59 % bei einem Recall von 82 % (Femmer et al., 2017). Ein Review im Team bleibt nötig.

Häufig gestellte Fragen

Wer schreibt die Akzeptanzkriterien einer User Story?

Der Product Owner verantwortet sie meist, geschrieben werden sie am besten gemeinsam mit Entwicklung und Test. Der ISTQB-Lehrplan beschreibt dafür den Spezifikations-Workshop, in dem das Team die Story analysiert und Kriterien festhält, bevor die Umsetzung beginnt.

Wie viele Kriterien braucht eine User Story?

Als Faustregel gelten 4 bis 8 Kriterien pro Story, so nennt es der QS-Baukasten des Bundesverwaltungsamts (BVA, 2024). Das ist eine Praxisregel, kein Standard. Deutlich mehr Kriterien deuten meist darauf hin, dass die Story zu groß ist und geteilt werden sollte.

Kommen Akzeptanzkriterien im Scrum Guide vor?

Nein, der Scrum Guide 2020 erwähnt weder Akzeptanzkriterien noch User Stories (Scrum Guide 2020, 2020). Er definiert die Definition of Done als Verpflichtung für das Increment. Sie sind eine ergänzende Praxis, die der ISTQB-Lehrplan in Abschnitt 4.5.2 beschreibt.

Sind Akzeptanzkriterien und Testfälle dasselbe?

Nein, Akzeptanzkriterien sind Testbedingungen und beschreiben, was geprüft wird; Testfälle legen mit Vorbedingungen, Eingaben und erwarteten Ergebnissen fest, wie. Das aktuelle ISTQB-Glossar sagt, ein Testfall werde „auf Basis von Testbedingungen“ entwickelt. Ein Kriterium ergibt oft mehrere Testfälle.

Kann KI Akzeptanzkriterien schreiben?

Sprachmodelle können Entwürfe liefern, die Verantwortung für die Kriterien bleibt beim Team. In der Studie von Ferreira et al. bewerteten die Beteiligten KI-erzeugte Gherkin-Szenarien in 95 % der Fälle als hilfreich (Ferreira et al., 2025). Autemos schreibt sie nicht; es setzt vorhandene Stories und Kriterien in ausführbare Tests um, mit Freigabe jedes Schritts.

Fazit

Akzeptanzkriterien sind die Testbedingungen einer User Story. Schreiben Sie sie vor der Umsetzung, eindeutig und mit konkreten Werten, und nehmen Sie die negativen Fälle von Anfang an auf. Gegeben/Wenn/Dann passt für Abläufe, eine Tabelle für Regeln mit vielen Kombinationen wie die Vier-Augen-Freigabe. Qualitätsmaßnahmen, die für jede Story gelten, gehören in die Definition of Done.

Für die Automatisierung zählt die Qualität der Kriterien. In der Studie von Ferreira et al. waren 60 % der KI-erzeugten Testabläufe direkt nutzbar, der Rest brauchte Korrekturen, mehr Eingaben oder wurde verworfen. Eine Freigabe pro Testschritt und die Verknüpfung in Jira und Xray zeigen später, welches Kriterium wie getestet wurde und mit welchem Ergebnis.

Wenn Sie sehen möchten, wie Autemos aus Ihren Jira-Stories freigegebene und nachverfolgbare Tests macht, vereinbaren Sie eine Demo.