Ein Prompt für Testfälle nimmt sich den langsamsten Schritt nach der Anforderungsbesprechung vor: Alle verstehen die Funktion, doch sobald jemand die Fälle aufschreibt, läuft der Normalfall glatt durch, während Grenzwerte und Fehlersituationen still unter den Tisch fallen und erst nach der Übergabe als Fehlerberichte wieder auftauchen. Der folgende Prompt legt Fallgruppen, Tabellenspalten und die Schreibweise der erwarteten Ergebnisse fest, bevor überhaupt etwas eingefügt wird, sodass am Ende eine Tabelle steht, die sich direkt ausführen oder in ein Testmanagement-Werkzeug importieren lässt.
Wann dieser Prompt passt
Er eignet sich, um Fälle vor der Übergabe einer neuen Funktion zu entwerfen, nach einer Überarbeitung eine Regressionsliste neu aufzubauen oder als Produktverantwortlicher die Abnahmekriterien selbst zu prüfen. Voraussetzung ist ein klar geschriebener Anforderungsabschnitt: eine Prototyp-Beschreibung, ein Abschnitt aus dem Lastenheft oder eine User Story genügen. Liegt nur ein mündlicher Satz vor, sollte er vorher zu einem kurzen Absatz mit Hintergrund, Einstieg, Regeln und Grenzen ausgearbeitet werden; die Qualität der Ausgabe hängt stark davon ab.
Der Prompt zum Kopieren
Du bist ein Software-Testingenieur mit 8 Jahren Erfahrung. Entwirf auf Grundlage der folgenden Anforderungen eine Reihe von Testfällen, die sich genau so ausführen lassen.
Anforderungen: {{Anforderungen}}
Zusatzinformationen: {{Zusatzinformationen, etwa betroffene Seiten oder Schnittstellen, Kontorollen, Datengrenzen; falls keine vorhanden, "keine" schreiben}}
Ausgaberegeln:
1. Gib eine Tabelle mit diesen Spalten in dieser Reihenfolge aus: Fallnummer, Falltitel, Vorbedingungen, Schritte, Testdaten, erwartetes Ergebnis, Priorität, Falltyp.
2. Die Falltypen müssen vier Gruppen abdecken: Normalfall, Grenzwerte, Fehler und ungültige Eingaben, Berechtigungen und Rollen, mit mindestens 3 Fällen pro Gruppe.
3. Grenzfälle müssen konkrete Zahlen nennen, etwa eine Längenobergrenze, eine Betragsgrenze oder ein Absendelimit; schreibe nicht einfach "Maximalwert eingeben".
4. Erwartete Ergebnisse müssen nachprüfbar sein: Benenne die genaue Meldung auf dem Bildschirm, die Datenänderung oder die Zustandsänderung; vermeide leere Formulierungen wie "funktioniert normal".
5. Füge nach der Tabelle einen eigenen Abschnitt "Offene Fragen an die Anforderungen" an und liste jede Unklarheit einzeln auf; erfinde keine Regeln, um Lücken zu füllen.
Gib zuerst die Tabelle aus, danach die offenen Fragen, ohne lange Einleitung vor der Tabelle.So füllst du die beiden Variablen
- {{Anforderungen}}: Füge den Anforderungstext vollständig ein, inklusive Geschäftsregeln, Feldgrenzen und Zustandsübergängen. Je konkreter, desto besser. Steht dort nur "eine Gutscheinfunktion bauen", kann das Modell nur nach allgemeinen Shop-Regeln raten, und die geratenen Fälle passen nicht zu den echten Regeln.
- {{Zusatzinformationen}}: Halte fest, was beim Testen tatsächlich vorliegt, etwa welche Kontorollen es gibt, ob fertige Testdaten vorhanden sind und ob die Funktion in einer App oder im Browser läuft. Die Rollenangabe ist am wichtigsten, weil alle Berechtigungsfälle daraus entstehen.
Wie ein ausgefüllter Durchlauf aussieht
Ersetzt du die Anforderungen durch einen kurzen Absatz, "Nutzer können ihre Lieferadresse ändern; der Adresstext ist auf 100 Zeichen begrenzt; Bundesland, Stadt und Bezirk sind Pflichtfelder; die neue Adresse gilt sofort nach dem Speichern", enthält die zurückgegebene Tabelle Zeilen wie diese:
| Nr. | Titel | Testdaten | Erwartetes Ergebnis | Typ |
|---|---|---|---|---|
| TC-04 | Adresse mit genau 100 Zeichen speichern | Eine Adresse mit genau 100 Zeichen | Speichern gelingt, die Listenansicht zeigt die volle Adresse | Grenzwert |
| TC-05 | Adresse mit 101 Zeichen speichern | Eine Adresse mit 101 Zeichen | Speichern wird mit einer Meldung zur Längenbegrenzung blockiert | Grenzwert |
| TC-09 | Speichern ohne gewählten Bezirk | Bundesland und Stadt gewählt, Bezirk leer | Der Fokus springt zum Bezirksfeld, mit einer Pflichtfeld-Meldung | Fehler |
Zeilen mit konkreten Zahlen wie diesen zeigen, dass der Prompt greift. Lesen sich alle Titel wie "Speichern prüfen", wiederhole die Regeln 3 und 4 mit Nachdruck und starte erneut.
Nachfrage, wenn das Ergebnis enttäuscht
- Fälle zu flach: "Behalte nur die Fälle mit hoher Priorität und ergänze zu jedem eine Gegenprobe: Wie muss das System eine absichtlich falsche Eingabe blockieren?"
- Wiederholtes Absenden fehlt: Ergänze in den Zusatzinformationen "derselbe Nutzer kann mehrmals hintereinander auf Speichern klicken" und bitte um eine Gruppe "wiederholte Aktionen".
- Automatisierung gewünscht: "Schreibe die Fälle mit hoher Priorität als Playwright-Testschritte um, mit Lokatoren und Prüfungen zu jedem Fall."
Ein letzter Hinweis: Von KI erzeugte Fälle taugen gut als erster Entwurf und als Lückenliste. Fälle rund um Zahlungen, Berechtigungen oder das Löschen von Daten muss ein menschlicher Tester vor der Auslieferung trotzdem einzeln in der echten Umgebung ausführen, und die unter den offenen Fragen gelisteten Unklarheiten sind meist genau die Punkte, die in der Besprechung niemand zu Ende gedacht hatte.
