| name | generate-test-cases |
| description | Derives manual test cases from a requirement and saves them directly as a CSV file optimized for Xray import. Use when asked to create, derive, or write manual test cases from a requirement, user story, or ticket. |
Generate Manual Test Cases
Dieser Skill leitet aus einer Anforderung manuelle Testfälle ab und speichert sie direkt als CSV-Datei für den Xray-Import. Im Chat erscheint kein Markdown und keine Tabelle — einziges Ergebnis ist die gespeicherte CSV-Datei.
Use When
- Du sollst manuelle Testfälle aus einer Anforderung, User Story oder einem Ticket erstellen
- Du wirst gebeten, Testfälle für einen bestimmten Funktionsbereich abzuleiten
Do Not Use When
- Es sollen Playwright-/automatisierte Tests in TypeScript geschrieben werden (normaler Coding-Workflow)
- Es wird nur eine Erklärung oder Analyse einer Anforderung gewünscht, keine Testfälle
- Es sollen Gherkin-Tests geschrieben werden
Step 0 — Kontext sammeln (einmalig je Aufgabe)
Schritt 1 — Format per Tool abfragen
Nutze das vscode_askQuestions-Tool und stelle genau diese eine Frage:
- Frage: "Wie sollen die Testfälle strukturiert werden?"
- Optionen (Einzelauswahl, kein Freitext):
- Multi-Test — Jedes Szenario bekommt eine eigene TCID
- Single-Test — Alle Prüfungen in einem einzigen Testfall; jede Prüfung wird ein eigener Testschritt
Warte auf die Antwort, bevor du fortfährst.
Schritt 2 — Restliche Angaben im Chat erfragen
Stelle dem User im Chat folgende Fragen als formatierte Liste. Warte auf die Antwort, bevor du fortfährst:
- Anforderung: Was soll getestet werden? (User Story, Freitext, Ticket-Inhalt)
- Testtiefe: Welche Testarten sollen abgedeckt werden? (Mehrfachauswahl möglich)
- Positiv-Tests (Happy Path)
- Negativ-Tests (Fehlerfälle, ungültige Eingaben)
- Grenzwert-Tests
- Kombinationen der obigen
- Metadaten für alle Testfälle dieser Aufgabe:
- Tests (Ticket-ID, z.B.
"SPSH-234")
- Beschreibung (z.B.
"Test aus Playwright importiert.")
- Testplan (Ticket-ID des zugehörigen Testplans, z.B.
"SPSH-3163")
- Stichwörter (eine oder mehrere, z.B.
"Automatisiert", "Beschrieben" — jedes Stichwort ergibt eine eigene Spalte in der Tabelle)
- Autor (z.B.
"silvia.grosche")
- Repo (z.B.
"Automatisierung/Navigieren")
- Prio (
"low", "medium" oder "high")
Fahre erst fort, wenn alle Angaben vorliegen.
Step 0b — Anforderungstext vorverarbeiten (intern — keine Ausgabe)
Ersetze in der gegebenen Anforderung die folgenden Zeichen, bevor du Testfälle ableitest. Dieser Schritt gilt für den gesamten Anforderungstext inkl. Akzeptanzkriterien und Scope. Gib das Ergebnis nicht aus.
| Zeichen | Ersetzung |
|---|
" | ' |
ä | ae |
ö | oe |
ü | ue |
ß | ss |
Step 1 — Testfälle ableiten
Leite aus der Anforderung Testfälle ab. Wende je nach gewähltem Format eine der beiden folgenden Strategien an:
Format: Multi-Test (Standard)
- Decke alle vom User gewählten Testarten ab (Positiv, Negativ, Grenzwerte, Kombinationen)
- Alle Schritte eines Testszenarios (Vorbedingungen + fachliche Aktion) gehören in die erste Tabellenzeile. Folgezeilen mit gleicher TCID beschreiben sequenzielle, aufbauende Schritte — sie enthalten nur die Delta-Aktion (was sich gegenüber dem Vorgänger ändert), keinen wiederholten Setup.
- Eine neue TCID entsteht nur, wenn der Test von vorne beginnt (neuer Kontext, komplett neues Setup). Sequenziell aufbauende Varianten (z.B. schrittweise veränderte Testdaten im gleichen Ablauf) bleiben in einer TCID.
- Es wird nur geprüft, was die Anforderung betrifft. Vorbereitende Schritte (Anmelden, Navigation) sind keine eigenen Prüfschritte und erzeugen kein eigenes Erwartetes Ergebnis.
Format: Single-Test
- Es gibt genau eine TCID für die gesamte Anforderung.
- Die erste Tabellenzeile enthält Vorbedingungen und den ersten Prüfschritt.
- Jede weitere zu prüfende Bedingung aus der Anforderung wird eine eigene Folgezeile mit derselben TCID — die Aktion beschreibt die Delta-Aktion bzw. den nächsten Prüfschritt, das Erwartete Ergebnis das zugehörige Prüfergebnis.
- Vorbereitende Schritte (Anmelden, Navigation) stehen nur in der ersten Zeile und erzeugen kein eigenes Erwartetes Ergebnis.
- Es wird nur geprüft, was die Anforderung betrifft.
Step 2 — Markdown-Tabelle aufbauen (kein Chat-Output)
Dieser Step wird intern ausgeführt — es erscheint keine Ausgabe im Chat.
2a — Interne Markdown-Tabelle aufbauen
Baue die Testfälle als interne Markdown-Tabelle mit exakt diesen Spalten in dieser Reihenfolge auf:
TCID | tests | Zusammenfassung | Beschreibung | Aktion | Data | Erwartetes Ergebnis | Testplan | Autor | Stichwort | [Stichwort | ...] | Prio | Repo
Jedes vom User angegebene Stichwort erhält eine eigene Spalte, alle mit der Überschrift Stichwort.
Tabellenregeln:
- TCID: Fortlaufende Nummer, startet bei
1. Ein Testfall kann mehrere Zeilen haben — alle Zeilen desselben Tests erhalten dieselbe TCID.
- Metadaten-Regel: Die Felder tests, Zusammenfassung, Beschreibung, Testplan, Autor, Stichwörter, Prio und Repo stehen nur in der ersten Zeile eines Tests — Folgezeilen dieser Spalten bleiben leer. Das Feld Data wird in jeder Zeile ausgefüllt (mindestens
-).
- Zusammenfassung: Format
<tests>: <kurze Testbeschreibung> (z.B. SPSH-234: Login mit gueltigen Daten).
- Aktion: Alle Schritte des Testszenarios, jeder präfixiert mit
# . Beginnt mit Vorbereitungsschritten (Anmelden, Navigation), endet mit der fachlich relevanten Aktion. Beim Anmelde-Schritt steht ausschließlich die Rollenbezeichnung (z.B. # Als Schuladmin anmelden). Niemals Systemrechte oder Account-Details in die Aktion — diese gehören in Data. Unter-Schritte werden mit ## präfixiert.
Formatierungskonventionen (innerhalb der Aktion-Zelle, Schritte durch <br> getrennt):
- Buttons →
*...*: z.B. *Schliessen* klicken
- UI-Elemente, Eigennamen, Seitentitel →
_..._: z.B. _Klassenverwaltung_ oeffnen
- Gesuchte Texte, Meldungen →
_..._: z.B. _Erfolgsmeldung: Der Vorgang wurde ausgefuehrt._
- Data: Testdaten passend zum Aktionsschritt dieser Zeile. Wenn keine Daten relevant sind:
-.
- Erwartetes Ergebnis: Das fachlich relevante Prüfergebnis der Zeile, ohne
# Präfix. Pro Tabellenzeile genau ein Erwartetes Ergebnis — das des letzten anforderungsrelevanten Schritts.
Step 3 — Self-Check auf Markdown-Tabelle (intern — keine Ausgabe)
Prüfe die Markdown-Tabelle aus Step 2a intern und korrigiere Fehler, bevor mit Step 4 fortgefahren wird. Gib diesen Check nicht aus:
- Die Spaltenanzahl ist in jeder Tabellenzeile konsistent
- Metadaten (tests, Zusammenfassung, Beschreibung, Testplan, Autor, Stichwörter, Prio, Repo) stehen nur in der ersten Zeile je TCID — Folgezeilen dieser Spalten sind leer
- Das Feld Data ist in jeder Zeile ausgefüllt (mindestens
-)
- Die Zusammenfassung folgt dem Format
<tests>: <kurze Testbeschreibung>
- TCIDs sind konsistent fortlaufend (1, 2, 3, …)
Step 4 — Markdown-Datei speichern und Skript ausführen (kein Chat-Output)
Dieser Step wird intern ausgeführt — es erscheint keine Ausgabe im Chat.
4a — Markdown-Datei speichern
Speichere die Markdown-Tabelle aus Step 2a mit create_file als:
- Pfad:
.github/manual_tests/<TICKET-ID>-testfaelle.md
<TICKET-ID>: Ticket-ID in Originalschreibweise, z.B. SPSH-3353
4b — Skript aufrufen
Führe das Konvertierungsskript mit run_in_terminal aus:
python .github/scripts/md_to_csv.py .github/manual_tests/<TICKET-ID>-testfaelle.md --delete-input
--delete-input löscht die Markdown-Zwischendatei nach erfolgreicher Konvertierung automatisch.- Prüfe den Exit-Code: Bei Fehler (Exit-Code ≠ 0) die Fehlermeldung aus stderr im Chat ausgeben und abbrechen.
Step 5 — Abschluss
Einzige Ausgabe im Chat nach erfolgreichem Skript-Lauf:
CSV gespeichert: .github/manual_tests/<TICKET-ID>-testfaelle.csv
When the Skill Cannot Proceed
Stop und informiere den User, wenn:
- Die Anforderung zu vage ist, um konkrete Testschritte abzuleiten — bitte um Präzisierung
- Kein erwartetes Verhalten aus der Anforderung erkennbar ist — frage nach dem Akzeptanzkriterium
