31. Dez. 2025·7 Min
Akzeptanztests aus Prompts: Features in Szenarien verwandeln
Lerne, wie du aus Feature‑Prompts 5–10 klare Akzeptanzszenarien machst, die Happy Path und Randfälle abdecken — ohne aufgeblähte Test‑Suiten.
Lerne, wie du aus Feature‑Prompts 5–10 klare Akzeptanzszenarien machst, die Happy Path und Randfälle abdecken — ohne aufgeblähte Test‑Suiten.
Chat-artige Feature-Prompts wirken eindeutig, weil sie wie ein Gespräch lesen. Dennoch bündeln sie oft Entscheidungen, Regeln und Ausnahmen in ein paar freundliche Sätze. Die Lücken zeigen sich erst, wenn jemand das Feature tatsächlich benutzt.
Die meisten Prompts beruhen stillschweigend auf Annahmen: wer die Aktion ausführen darf, was als „Erfolg“ zählt (gespeichert, gesendet, veröffentlicht, bezahlt), was passiert, wenn Daten fehlen, und was der Nutzer sehen soll, wenn etwas fehlschlägt. Sie verbergen auch vage Standards wie „schnell genug“ oder „sicher genug“.
Mehrdeutigkeiten tauchen meist spät als Bugs und Nacharbeit auf. Ein Entwickler baut das, was er aus dem Prompt versteht, ein Reviewer akzeptiert es, weil es richtig aussieht, und dann stoßen Nutzer auf seltsame Fälle: doppelte Einreichungen, Zeitzonen, partielle Daten oder Berechtigungsfehler. Das spätere Beheben kostet mehr, weil es oft Code, UI‑Texte und manchmal das Datenmodell berührt.
Qualität braucht keine riesigen Test-Suiten. Sie bedeutet, dass du dem Feature im normalen Gebrauch und unter vorhersehbarer Last vertrauen kannst. Eine kleine Menge gut gewählter Szenarien gibt dieses Vertrauen, ohne Hunderte von Tests.
Eine praktische Definition von Qualität für aus Prompts gebaute Features:
Darum geht es beim Umwandeln von Prompts in Akzeptanzszenarien: eine unscharfe Anforderung in 5–10 Prüfungen übersetzen, die die versteckten Regeln früh sichtbar machen. Du versuchst nicht, alles zu testen. Du versuchst, die Fehler zu fangen, die tatsächlich passieren.
Wenn du aus einem schnellen Prompt in einem Chat‑Coder‑Tool wie Koder.ai baust, kann die Ausgabe komplett wirken und dennoch Randregeln überspringen. Ein schlanker Satz von Szenarien zwingt dazu, diese Regeln zu benennen, solange Änderungen noch günstig sind.
Ein Akzeptanztestszenario ist eine kurze, verständliche Beschreibung einer Nutzeraktion und des Ergebnisses, das er sehen sollte.
Bleib an der Oberfläche: was der Nutzer tun kann und was das Produkt zeigt oder ändert. Vermeide interne Details wie Datenbanktabellen, API‑Aufrufe, Background‑Jobs oder welches Framework verwendet wird. Diese Details können später wichtig werden, machen Szenarien aber brüchig und schwerer zu vereinbaren.
Ein gutes Szenario ist außerdem unabhängig. Es sollte morgen einfach in einer sauberen Umgebung ausführbar sein, ohne davon abzuhängen, dass ein anderes Szenario vorher gelaufen ist. Falls ein Szenario von einem vorherigen Zustand abhängt, sag das klar im Setup (z. B. „der Nutzer hat bereits ein aktives Abo“).
Viele Teams verwenden Given‑When‑Then, weil es Klarheit erzwingt, ohne Szenarien in ein vollständiges Spec zu verwandeln.
Ein Szenario gilt in der Regel als „erledigt“, wenn es ein Ziel hat, einen klaren Startzustand, eine konkrete Aktion und ein sichtbares Ergebnis. Es sollte binär sein: Jeder im Team kann nach dem Ausführen „Bestanden“ oder „Nicht bestanden“ sagen.
Beispiel: „Given ein angemeldeter Nutzer ohne gespeicherte Zahlungsmethode, when er Pro wählt und die Zahlung bestätigt, then sieht er eine Erfolgsmeldung und der Plan wird in seinem Account als Pro angezeigt."
Wenn du in einem Chat‑First‑Builder wie Koder.ai baust, gilt dieselbe Regel: teste das Verhalten der generierten App (was der Nutzer erlebt), nicht wie die Plattform den Code erzeugt hat.
Das beste Format ist das, das Leute schreiben und lesen. Wenn die Hälfte des Teams lange Narrative nutzt und die andere Hälfte knappe Stichpunkte, entstehen Lücken, Duplikate und Streit über die Formulierung, statt über Qualität.
Given‑When‑Then funktioniert gut, wenn das Feature interaktiv und zustandsbehaftet ist. Eine einfache Tabelle ist praktisch, wenn du viele ähnliche Input‑Output‑Regeln hast.
Wenn dein Team gespalten ist, wählt für 30 Tage ein Format und passt es danach an. Wenn Reviewer ständig fragen „Wie sieht Erfolg aus?“, ist das ein Zeichen, zu Given‑When‑Then zu wechseln. Wenn Szenarien zu ausschweifend werden, ist eine Tabelle oft leichter zu überfliegen.
Egal, was ihr wählt: standardisiert es. Behaltet die gleichen Überschriften, die gleiche Zeitform und das gleiche Detailniveau. Vereinbart auch, was nicht rein gehört: pixelgenaue UI‑Details, Implementierungsdetails und Datenbanktalk. Szenarien sollten beschreiben, was ein Nutzer sieht und welche Garantien das System liefert.
Leg Szenarien dort ab, wo bereits gearbeitet wird, und halte sie nah am Feature.
Gängige Optionen sind: neben dem Produktcode, im Ticket unter einer Sektion „Acceptance scenarios“ oder in einem geteilten Doc mit einer Seite pro Feature. Wenn du Koder.ai verwendest, kannst du Szenarien auch im Planning Mode speichern, damit sie mit der Build‑Historie zusammenbleiben – inklusive Snapshots und Rollbacks.
Wichtig ist: suchbar machen, eine Quelle der Wahrheit behalten und Szenarien verlangen, bevor Entwicklung als „gestartet“ gilt.
Beginne damit, den Prompt als Nutzerziel plus klares Ende umzuschreiben. Nutze einen Satz für das Ziel (wer will was), dann 2–4 Erfolgskriterien, die du ohne Diskussion überprüfen kannst. Wenn du kein sichtbares Ergebnis benennen kannst, hast du noch keinen Test.
Zerlege den Prompt als Nächstes in Eingaben, Ausgaben und Regeln. Eingaben sind das, was der Nutzer liefert oder auswählt. Ausgaben sind das, was das System anzeigt, speichert, sendet oder blockiert. Regeln sind die „nur wenn“‑ und „muss“‑Aussagen, die zwischen den Zeilen stehen.
Prüfe dann, wovon das Feature abhängt, bevor es funktionieren kann. Hier verstecken sich oft Szenariolücken: erforderliche Daten, Nutzerrollen, Berechtigungen, Integrationen und Systemzustände. Wenn du z. B. in Koder.ai baust, klär, ob der Nutzer angemeldet sein muss, ein Projekt angelegt sein muss oder ein Plan/Access erforderlich ist.
Schreib nun die kleinste Menge Szenarien, die beweist, dass das Feature funktioniert: üblicherweise 1–2 Happy Paths und dann 4–8 Randfälle. Halte jedes Szenario auf einen Grund zu scheitern fokussiert.
Gute Randfälle (nur was zum Prompt passt): fehlende oder ungültige Eingabe, Berechtigungsinkongruenz, Zustandkonflikte wie „bereits eingereicht“, Integrationsprobleme wie Timeouts und Recovery‑Verhalten (klare Fehler, sichere Wiederholung, keine Teilspeicherung).
Schließe mit einem schnellen „Was könnte schiefgehen?“ ab. Achte auf stille Fehlschläge, verwirrende Meldungen und Stellen, an denen falsche Daten erstellt werden könnten.
Ein Happy‑Path‑Szenario ist die kürzeste, normalste Route, bei der alles glatt läuft. Wenn du es bewusst langweilig hältst, wird es zur verlässlichen Basis, die Randfälle leichter sichtbar macht.
Nenne den Default‑Nutzer und die Default‑Daten. Verwende eine reale Rolle, nicht nur „Nutzer“: „angemeldeter Kunde mit verifizierter E‑Mail“ oder „Admin mit Bearbeitungsberechtigung für Abrechnung“. Dann definiere die kleinstmöglichen Beispiel‑Daten: ein Projekt, ein Eintrag in einer Liste, eine gespeicherte Zahlungsmethode. Das macht Szenarien konkret und reduziert versteckte Annahmen.
Schreib zuerst den kürzesten Weg zum Erfolg. Entferne optionale Schritte und Alternativflüsse. Wenn das Feature „Aufgabe erstellen“ ist, sollte der Happy Path keine Filterung, Sortierung oder Nachbearbeitung enthalten.
Eine einfache Kontrolle, um es knapp zu halten: bestätige vier Dinge:
Füge dann eine Variante hinzu, die nur eine Variable ändert. Wähle die Variable, die später am wahrscheinlichsten Probleme macht, z. B. „Titel ist lang“ oder „Nutzer hat keine vorhandenen Elemente“, und halte sonst alles identisch.
Beispiel: Wenn dein Prompt sagt „Nach dem Speichern einen 'Snapshot erstellt' Toast anzeigen“, ist der Happy Path: Nutzer klickt auf Create Snapshot, sieht einen Ladezustand, bekommt „Snapshot erstellt“ und der Snapshot erscheint in der Liste mit richtiger Zeitstempelung. Eine Ein‑Variablen‑Variante könnte dieselben Schritte mit leerem Namen und einer klaren Default‑Namensregel sein.
Randfälle verbergen die meisten Bugs, und du brauchst keine riesige Suite, um sie zu erwischen. Pro Feature‑Prompt wählst du eine kleine Menge, die reales Verhalten und reale Fehlermodi widerspiegelt.
Häufige Kategorien:
Nicht jedes Feature braucht jede Kategorie. Eine Suchbox kümmert sich mehr um Eingaben; ein Zahlungsfluss mehr um Integrationen und Daten.
Wähle Randfälle, die Risiko widerspiegeln: hoher Schaden bei Fehlern (Geld, Sicherheit, Datenschutz), hohe Häufigkeit, leicht zu brechende Flows, bekannte Bugs oder Probleme, die nachträglich schwer zu erkennen sind.
Beispiel: Beim „Abo wechseln“-Feature zahlen sich Szenarien wie Session‑Ablauf beim Checkout, Doppelklick auf „Bestätigen“ und ein Timeout beim Zahlungsanbieter oft aus.
Beispiel‑Feature‑Prompt (einfach):
„Wenn ich etwas kaputt mache, möchte ich meine App zu einem vorherigen Snapshot zurückrollen, damit die letzte funktionierende Version wieder live ist."
Unten ein kompakter Szenariensatz. Jedes Szenario ist kurz, aber es legt ein Ergebnis fest.
S1 [Must‑have] Zur letzten Snapshot‑Version zurückrollen
Given ich bin eingeloggt und ich besitze die App
When ich „Rollback“ wähle und bestätige
Then wird die vorherige Snapshot‑Version deployed und der App‑Status zeigt die neue Version als aktiv an
S2 [Must‑have] Zu einer bestimmten Snapshot‑Version zurückrollen
Given ich sehe die Snapshot‑Liste für meine App
When ich Snapshot „A“ auswähle und den Rollback bestätige
Then wird Snapshot „A“ aktiv und ich sehe, wann er erstellt wurde
S3 [Must‑have] Nicht erlaubt (Auth)
Given ich bin eingeloggt, habe aber keinen Zugriff auf diese App
When ich versuche zurückzurollen
Then sehe ich einen Zugriffsfehler und kein Rollback startet
S4 [Must‑have] Snapshot nicht gefunden (Validierung)
Given eine Snapshot‑ID existiert nicht (oder wurde gelöscht)
When ich versuche, zu ihr zurückzurollen
Then erhalte ich eine klare „Snapshot nicht gefunden“‑Meldung
S5 [Must‑have] Doppelte Bestätigung (Duplikate)
Given ich klicke sehr schnell zweimal auf „Rollback bestätigen“
When die zweite Anfrage gesendet wird
Then läuft nur ein Rollback und ich sehe ein einzelnes Ergebnis
S6 [Must‑have] Deployment‑Fehler (Fehlerfälle)
Given der Rollback startet
When das Deployment fehlschlägt
Then bleibt die aktuell aktive Version live und der Fehler wird angezeigt
S7 [Nice‑to‑have] Timeout oder Verbindungsverlust
Given meine Verbindung bricht während des Rollbacks ab
When ich die Seite neu lade
Then kann ich sehen, ob der Rollback noch läuft oder bereits beendet ist
S8 [Nice‑to‑have] Bereits auf diesem Snapshot
Given Snapshot „A" ist bereits aktiv
When ich versuche, zu Snapshot „A" zurückzurollen
Then werde ich informiert, dass sich nichts geändert hat und kein neues Deployment startet
Jedes Szenario beantwortet drei Fragen: wer macht es, was er tut und was danach wahr sein muss.
Ziel ist nicht „alles testen“. Ziel ist, die Risiken abzudecken, die Nutzer schädigen würden, ohne einen Stapel Szenarien zu erzeugen, den niemand ausführt.
Ein praktischer Trick: kennzeichne Szenarien nach erwarteter Nutzung:
Beschränke dich auf ein Szenario pro unterscheidbarem Risiko. Scheitern zwei Szenarien aus demselben Grund, brauchst du wahrscheinlich nur ein Szenario. „Ungültiges E‑Mail‑Format“ und „fehlende E‑Mail“ sind verschiedene Risiken. Aber „fehlende E‑Mail in Schritt 1“ und „fehlende E‑Mail in Schritt 2“ sind vielleicht dasselbe Risiko, wenn die Regel identisch ist.
Vermeide auch, UI‑Schritte in vielen Szenarien zu duplizieren. Halte Wiederholungen kurz und fokussiere auf das, was sich ändert. Das ist besonders wichtig bei Chat‑basierten Tools wie Koder.ai, weil die UI sich ändern kann, während die Geschäftsregel gleich bleibt.
Entscheide außerdem, was jetzt geprüft wird vs. später. Manche Checks sind zunächst besser manuell und später automatisiert:
Ein Szenario sollte dich vor Überraschungen schützen, nicht beschreiben, wie das Team das Feature bauen will.
Der häufigste Fehler ist, ein Nutzerziel in eine technische Checkliste zu verwandeln. Wenn das Szenario sagt „API gibt 200 zurück“ oder „Tabelle X hat Spalte Y“, bindet es dich an ein Design und beweist nicht, dass der Nutzer das bekam, was er brauchte.
Ein weiteres Problem ist, mehrere Ziele in ein langes Szenario zu packen. Es liest sich wie eine komplette Reise, aber wenn es fehlschlägt, weiß niemand, warum. Ein Szenario sollte eine Frage beantworten.
Sei vorsichtig mit Randfällen, die clever klingen, aber unrealistisch sind. „Nutzer hat 10 Millionen Projekte“ oder „Netzwerk bricht alle 2 Sekunden ab“ entspricht selten der Realität und ist schwer zu reproduzieren. Wähle Randfälle, die du in Minuten einrichten kannst.
Vermeide vage Ergebnisse wie „funktioniert“, „keine Fehler“ oder „erfolgreich“. Diese Wörter verbergen das genaue Ergebnis, das du verifizieren musst.
Für ein Feature wie Koder.ais „Quellcode exportieren“ ist ein schwaches Szenario: „Wenn Nutzer auf Export klickt, zippt das System das Repo und gibt 200 zurück." Das testet eine Implementierung, nicht das Versprechen.
Ein besseres Szenario: „Given ein Projekt mit zwei Snapshots, when der Nutzer exportiert, then enthält der Download den Code des aktuellen Snapshots und das Export‑Log verzeichnet, wer wann exportiert hat."
Vergiss nicht die „Nein“-Pfade: „Given ein Nutzer ohne Exportberechtigung, when er versucht zu exportieren, then ist die Option verborgen oder gesperrt und es wird kein Export‑Log erstellt." Eine Zeile kann sowohl Sicherheit als auch Datenintegrität schützen.
Bevor ein Szenarienset als „fertig“ gilt, lies es wie ein pingeliger Nutzer und wie eine Datenbank. Wenn du nicht sagen kannst, was vor dem Test wahr sein muss oder wie „Erfolg“ aussieht, ist es nicht bereit.
Ein gutes Set ist klein, aber konkret. Du solltest es jemandem geben können, der das Feature nicht geschrieben hat, und dieselben Ergebnisse bekommen.
Verwende diesen schnellen Pass zur Abnahme (oder zur Rückgabe) der Szenarien:
Wenn du Szenarien in einem Chat‑basierten Builder wie Koder.ai generierst, bestehe auf demselben Standard: kein vages „funktioniert wie erwartet“. Fordere beobachtbare Ausgaben und gespeicherte Änderungen, und genehmige nur, was du verifizieren kannst.
Mach das Schreiben von Szenarien zu einem echten Schritt in deinem Prozess, nicht zur Aufräumarbeit am Ende.
Schreibe Szenarien, bevor die Implementierung startet, solange das Feature noch günstig zu ändern ist. Das zwingt das Team, die unbequemen Fragen früh zu beantworten: was „Erfolg" heißt, was bei fehlerhaften Eingaben passiert und was ihr noch nicht unterstützen wollt.
Nutze Szenarien als gemeinsame Definition von "Done". Product owns Intent, QA owns Risk Thinking und Engineering owns Feasibility. Wenn alle drei dieselben Szenarien lesen und zustimmen, vermeidest du, etwas als „fertig“ zu schicken, das nicht akzeptabel ist.
Ein Workflow, der in den meisten Teams funktioniert:
Wenn du in Koder.ai arbeitest (koder.ai), hilft es, Szenarien zuerst zu entwerfen und dann im Planning Mode jeden Szenario‑Schritt auf Bildschirme, Datenregeln und sichtbare Ergebnisse zu mappen, bevor du Code generierst oder änderst.
Für riskante Änderungen: nimm einen Snapshot, bevor du iterierst. Wenn ein neuer Randfall einen funktionierenden Flow bricht, kann Rollback dir einen Tag Arbeit ersparen.
Bewahre Szenarien neben dem Feature‑Request (oder im selben Ticket) auf und behandle sie wie versionierte Anforderungen. Wenn Prompts sich weiterentwickeln, sollte das Szenarienset mitwandern, sonst driftet dein "Done" stillschweigend davon.
Beginne mit einem Satz, der das Benutzerziel und die Ziellinie beschreibt.
Zerlege den Prompt dann in:
Daraus schreibst du 1–2 Happy Paths und 4–8 Randfälle, die reale Risiken abdecken (Berechtigungen, Duplikate, Timeouts, fehlende Daten).
Weil Prompts Annahmen verbergen. Ein Prompt kann sagen „speichern“, ohne zu definieren, ob das Entwurf vs. Veröffentlicht heißt, was bei einem Fehler passiert oder wer das darf.
Szenarien zwingen dich, die Regeln früh zu benennen, bevor du Bugs wie doppelte Einreichungen, Berechtigungsfehler oder inkonsistente Ergebnisse verschickst.
Nutze Given–When–Then, wenn das Feature Zustand und Interaktion hat.
Nutze eine einfache Eingabe/Ausgabe-Tabelle, wenn viele ähnliche Regelprüfungen nötig sind.
Wähle für einen Monat ein Format und standardisiere es (gleiche Zeitform, gleicher Detailgrad). Das beste Format ist das, das dein Team tatsächlich benutzt.
Ein gutes Szenario ist:
Es ist "fertig", wenn jeder es ausführen kann und ohne Debatte über das Ergebnis urteilen kann.
Konzentriere dich auf beobachtbares Verhalten:
Vermeide Implementierungsdetails wie Datenbanktabellen, API-Antwortcodes, Background-Jobs oder Frameworks. Diese Details ändern sich oft und beweisen nicht, dass der Nutzer das Ergebnis erhalten hat.
Schreibe den langweiligsten, normalen Pfad, in dem alles funktioniert:
Bestätige dann vier Dinge: richtige Ansicht/Zustand, klare Erfolgsmeldung, Daten wurden gespeichert und der Nutzer kann sinnvoll weitermachen.
Wähle Randfälle nach Risiko und Häufigkeit:
Ziel: , nicht jede Variation testen.
Mach es sicher und klar:
Ein Fehler-Szenario sollte beweisen, dass das System Daten nicht korrupt macht oder den Nutzer nicht in die Irre führt.
Behandle Koder.ai-Ausgaben wie jede andere App: teste was der Nutzer erlebt, nicht wie der Code erzeugt wurde.
Praktischer Ablauf:
Bewahre sie dort auf, wo gearbeitet wird, und halte eine Quelle der Wahrheit:
Wenn du Koder.ai nutzt, halte Szenarien im Planning Mode, damit sie an die Build-Historie gebunden bleiben. Und am wichtigsten: require Szenarien bevor Entwicklung als gestartet gilt.