TC Review Workflow

Inhalt

Fortschritts-Checkliste
Disziplin
Das eherne Gesetz
Ablehnung zuerst (Vorbedingungs-Prüfung)
Schritt 1 — Beide Quellen wörtlich laden [mittlere Freiheit]
Schritt 2 — Rückverfolgbarkeitsmatrix erstellen [mittlere Freiheit]
Schritt 3 — Zeilenqualitätsprüfung [mittlere Freiheit]
Schritt 3b — Quellendurchlauf vor „PO/Reporter fragen“ (obligatorisch) [geringe Freiheit]
Schritt 4 — Bericht „Gut“ vs. „Verbesserungswürdig“ [mittlere Freiheit]
Schritt 5 — TC-Review-Kanal des Projekts benachrichtigen [geringe Freiheit]
QA-Abschluss (obligatorisch vor „erledigt“) [geringe Freiheit]
Skill-Zusammensetzung
Nicht im Umfang
MUSS / NIEMALS
Zu lesende Dateien
Abhängigkeiten

Beurteilen Sie ein Testfalldokument, das jemand bereits geschrieben hat — dieser Workflow entwirft oder bearbeitet selbst keine Testfälle. Er beantwortet eine Frage: Belegt dieses Dokument, wie geschrieben, dass die AC/EC und Geschäftsregeln des Tickets überprüft werden?

Slash-Command-Verknüpfung (für Laufzeitumgebungen, die Befehle unterstützen): /tc-review → commands/tc-review.md.

Fortschritts-Checkliste

Kopieren Sie diesen Block in Ihre Antwort, wenn die Ausführung startet, und haken Sie jede Zeile ab, sobald sie abgeschlossen ist. Eine fehlgeschlagene Prüfung sendet Sie zurück zu dem Schritt, der in der Zeile Gehe zurück: genannt wird — haken Sie ab dort ab.

TC-Review-Fortschritt:
- [ ] Ablehnung zuerst (Vorbedingungs-Prüfung)
- [ ] Schritt 1 — Beide Quellen wörtlich laden
- [ ] Schritt 2 — Rückverfolgbarkeitsmatrix erstellen
- [ ] Schritt 3 — Zeilenqualitätsprüfung
- [ ] Schritt 3b — Quellendurchlauf vor „PO/Reporter fragen“ (obligatorisch)
- [ ] Schritt 4 — Bericht „Gut“ vs. „Verbesserungswürdig“
- [ ] Schritt 5 — TC-Review-Kanal des Projekts benachrichtigen (nur den Thread erfragen)
- [ ] QA-Abschluss (obligatorisch vor „erledigt“)

Disziplin

Befolgen Sie shared-preamble.md und shared-must-never.md.

Das eherne Gesetz

KEINE FESTSTELLUNG OHNE EIN ZITIERTES QUELLE AUF BEIDEN SEITEN

Jede Feststellung vergleicht zwei Dinge, die tatsächlich in dieser Sitzung geöffnet wurden: den eigenen Text des TC-Dokuments und den eigenen AC/EC/Geschäftsregeln-Text des Tickets (oder eine Designquelle wie Figma/PRD, aber nur, nachdem sie tatsächlich geöffnet wurde). „Das TC sieht unvollständig aus“ aus einem allgemeinen Qualitätsgefühl heraus, ohne dass der Wortlaut des Tickets daneben zitiert wird, ist keine Feststellung — lesen Sie das Ticket, dann urteilen Sie. Eine Designquellen-Behauptung (exakter Kopietext, genauer UI-Zustand) ohne eine tatsächlich in dieser Sitzung geöffnete Quelle ist ebenfalls keine Feststellung — sagen Sie stattdessen „nicht verifiziert — konnte {Quelle} nicht öffnen“, anstatt zu raten.

Dies ist dieselbe Disziplin, die catch-ai-workflow für abgeschlossene Arbeiten im Allgemeinen anwendet; dieser Workflow ist seine TC-spezifische Instanz, die vor der Ausführung und nicht danach ausgeführt wird.

Ablehnung zuerst (Vorbedingungs-Prüfung)

DARF NICHT ohne beides beginnen:

das TC-Dokument — ein Blatt, CSV oder eine Markdown-Datei, die in dieser Sitzung erreichbar und lesbar ist;
das zugehörige Ticket — ein Jira-Issue-Key oder eine URL mit AC/EC (oder eine gleichwertige Spezifikationsquelle, die der Benutzer explizit nennt).

🔴 STOP — fehlt eines, stoppen Sie in einer Nachricht gemäß skill-rules-style.md.

Ticket organisations-/standortübergreifend: Wenn das Ticket auf einer Atlassian-Site lebt, auf die der verbundene MCP keinen Zugriff hat, sagen Sie dies und bitten Sie den Benutzer, den Zugriff zu gewähren (oder die AC/EC direkt einzufügen) — raten Sie niemals eine Cloud-ID, greifen Sie niemals auf einen Browser-Login zurück, um es zu lesen.

Schritt 1 — Beide Quellen wörtlich laden [mittlere Freiheit]

TC-Dokument — lesen Sie es so, wie es tatsächlich ist; geben Sie es beim Laden nicht um, fassen Sie es nicht zusammen und „bereinigen“ Sie keine Formulierungen. Notieren Sie die genaue Quelle (Blatt-ID + Tab/gid, Dateipfad oder URL), damit jedes spätere Zitat darauf verweisen kann.
Ticket — holen Sie AC, EC und alle Geschäftsregeln / Recheck-Listen aus den eigenen Feldern des Tickets (Beschreibung, benutzerdefinierte Felder — einige Projekte halten Inhalte vollständig von der Beschreibung fern; prüfen Sie beide). Zitieren Sie AC/EC-Bezeichnungen und -Text genau so, wie sie geschrieben sind; paraphrasieren Sie niemals aus dem Gedächtnis eines ähnlichen Tickets. Keine AC/EC in beiden Stellen gefunden → stoppen Sie gemäß der Ablehnungs-zuerst-Prüfung. Spezifikationstext gefunden, aber seine Elemente tragen keine AC/EC-Bezeichnungen → 🔴 STOP — zeigen Sie den gefundenen Text und fragen Sie den Benutzer, wie er nummeriert werden soll, bevor Sie mit Schritt 2 fortfahren; erfinden Sie niemals Bezeichnungen. Das Ticket oder das TC-Dokument wird mit Fehler abgerufen, läuft aus oder gibt teilweise Inhalte zurück (abgeschnittener Text, fehlende Felder, Tabs, die nicht laden) → teilen Sie dem Benutzer den genauen Fehler oder das Fehlende mit, erstellen Sie die Matrix nicht aus teilweisen AC/EC oder einem teilweisen TC-Dokument, übergeben Sie den Fehler an superpowers:systematic-debugging und nehmen Sie Schritt 1 erst wieder auf, wenn der vollständige Text geladen ist.
Wenn eine Designquelle (Figma, PRD) verlinkt ist und der Benutzer eine Gegenprüfung wünscht, öffnen Sie sie in dieser Sitzung. Wenn sie nicht geöffnet werden kann (keine Sitzung, kein Zugriff, Nur-Lesen ohne gerenderten Inhalt), dokumentieren Sie dies klar — es wird zu einem „nicht verifiziert“-Hinweis neben jeder zugehörigen Feststellung, niemals zu einem stillen Überspringen.

Schritt 2 — Rückverfolgbarkeitsmatrix erstellen [mittlere Freiheit]

Listen Sie für jede AC und EC auf dem Ticket auf, welche TC-Zeile(n) vorgeben, sie abzudecken:

AC/EC	Vorgegeben von	Status
`AC_01`	`TC_003`	abgedeckt
`AC_05`	—	kein TC — Lücke
`AC_02`	`TC_007`	falsch getaggt — `TC_007` Erwartetes Ergebnis stimmt mit `AC_04` überein
`EC_01`	`TC_010`, `TC_011`	inkonsistenter Tag — Geschwister-`TC_012` testet dasselbe Element ohne Tag

Status ist eine geschlossene Liste — verwenden Sie genau einen dieser vier Werte pro Zeile und benennen Sie die IDs wie gezeigt: abgedeckt · kein TC — Lücke · falsch getaggt — <TC> stimmt mit <AC/EC> überein · inkonsistenter Tag — <TC-IDs>. Eine Zeile mit mehreren Problemen nimmt das erste, das in dieser Reihenfolge nach abgedeckt zutrifft. Ein Loch in der eigenen AC-Liste des Tickets ist eine Lücke auf Spezifikationsebene, keine Matrixzeile — melden Sie es unter „Verbesserungswürdig“ als Spezifikationsfrage (siehe MUSS / NIEMALS).

Durchgestrichene AC/EC zählen nicht. Eine Zeile, die das Ticket durchgestrichen hat (z. B. -AC_07-, oft als Duplikat markiert) ist nicht im Umfang: lassen Sie sie aus der Matrix und vollständig aus dem Bericht heraus. Erwähnen Sie sie nicht, nicht einmal als „korrekt nicht abgedeckt“.

Geschäftsregeln und Ticketkommentare sind Kontext, keine zusätzlichen AC. Lesen Sie sie, um zu verstehen, was eine AC/EC bedeutet, und verwenden Sie sie, um zu beurteilen, ob ein TC das Richtige testet. Melden Sie ein Geschäftsregel- oder Kommentarelement nur, wenn es mit einer AC/EC in Konflikt steht, und nennen Sie die AC/EC, der es widerspricht. Ein Regel oder Kommentar, das kein TC hat, aber keiner AC/EC widerspricht, ist keine Feststellung. Lassen Sie es aus „Verbesserungswürdig“ heraus und fügen Sie keinen Abschnitt „Spezifikationsnotizen“ dafür hinzu.

Markieren Sie, unter Nennung der Zeilen-/AC-IDs:

eine AC/EC mit null TCs;
ein TC, dessen Erwartetes Ergebnis nachweislich mit einer anderen AC übereinstimmt als der, mit der es getaggt ist;
dasselbe Thema (z. B. ein gemeinsames UI-Element), das über Geschwisterzeilen hinweg inkonsistent getaggt ist — einige tragen eine AC, einige tragen keine, ohne angegebenen Grund.

Schritt 3 — Zeilenqualitätsprüfung [mittlere Freiheit]

Wenden Sie tc-quality-standards.md auf jede Zeile an und lesen Sie auf diese reviewspezifischen Fehlerformen (unterscheiden sich von der Autorenqualität — es geht um ein von jemand anderem geschriebenes Dokument, daher ist die Frage, ob es vertrauenswürdig ist, nicht ob es elegant ist):

Signal	Warum es wichtig ist
Schritte erreichen nicht den Zustand, den der Titel vorgibt. Eine Zeile mit dem Titel „Lerner sieht X“ stoppt bei Schritten, die auf der Hauptseite enden, und öffnet X nie tatsächlich.	Der Fall kann nicht verifizieren, was er zu verifizieren vorgibt.
Erwartetes Ergebnis ist der eigene Satz der AC, wörtlich kopiert, ohne Zerlegung. Wenn das Ticket mehrere konkrete Unterpunkte (Felder, Zustände, Schaltflächenvarianten) unter dieser AC auflistet, gibt ein Erwartetes Ergebnis, das nur den AC-Satz wiederholt, dem Tester nichts, um Zeile für Zeile zu prüfen.	Bestanden/Nicht bestanden wird zur Schätzung.
Die AC zählt benannte Fälle/Zustände auf (z. B. „Fall 1–6“, „laden / leer / filtern“-Zustände) und das Dokument hat eine allgemeine Zeile für alle.	Die meisten der aufgezählten Zustände bleiben ungetestet, obwohl die Zeile als erledigt markiert ist.
Testdaten haben keinen konkreten Wert, wo die AC einen benötigt (eine Grenzzahl, eine bestimmte Datumsbeziehung, eine benannte Filteroption).	Die Zeile kann nicht wie geschrieben ausgeführt werden — der Tester müsste den fehlenden Wert erfinden.
Die Zeile testet eine andere Bedingung als der Wortlaut der AC. Die AC sagt „bereits vorbeigescrollt“, aber die Zeile verwendet „bis zum Ende gesehen“. Die AC sagt „nur veröffentlichte Elemente“, aber das Erwartete Ergebnis prüft nie den Status.	Die Zeile kann bestehen, während die eigene Bedingung der AC ungetestet bleibt.
Das Erwartete Ergebnis ist vager, als es die eigenen Testdaten der Zeile zulassen. Die Testdaten geben jede Eingabe, die zur Berechnung der Antwort benötigt wird (Punktzahlen, Zählungen, eine Formel), aber das Erwartete Ergebnis sagt nur „korrekt sortiert“.	Der Tester muss den erwarteten Wert während des Durchlaufs ermitteln, sodass eine falsche Reihenfolge dennoch als Bestanden markiert werden kann.
Die Spalten der Zeile widersprechen sich gegenseitig. Die Vorbedingung sagt „4 Elemente“, aber die Testdaten listen 3 auf. Der Titel sagt „Status“, aber das Erwartete Ergebnis prüft nur die Reihenfolge.	Egal welcher Spalte der Tester folgt, die andere ist falsch.
Eine Ticket-Vorbedingung fehlt in jeder Zeile (z. B. „Benutzer ist angemeldet“).	Jede Zeile erbt einen nicht genannten Einrichtungsschritt.
Die Einrichtung nennt eine Methode, ohne sie anzugeben („es gibt eine Möglichkeit, die Anfrage fehlschlagen zu lassen“, „genügend Daten vorbereiten“).	Zwei Tester werden sie auf zwei verschiedene Arten einrichten.

Markieren Sie keine Testfall-Stilentscheidungen, die nicht beeinflussen, ob der Fall vertrauenswürdig ist (Namenskonvention, Spaltenreihenfolge, Prioritätskennzeichnungen), es sei denn, der Benutzer fragt explizit nach einer Stilüberprüfung. Dies setzt tc-quality-standards.md hier außer Kraft: Ignorieren Sie dessen Prioritätsattribut und seine Prüfungsbedingung „Prioritäten zugewiesen“-Zeile, es sei denn, der Benutzer fragt nach einer Stilüberprüfung.

Schritt 3b — Quellendurchlauf vor „PO/Reporter fragen“ (obligatorisch) [geringe Freiheit]

Dieser Workflow entscheidet niemals ein Produkturteil, aber er wirft Lücken und Fragen auf Spezifikationsebene auf. Bevor eine Feststellung zu „PO/Reporter fragen“ oder „Spezifikation unklar“ wird, führen Sie den Quellendurchlauf in Ebene 14 von result-quality-gate.md durch: den Produktcode im Standard-Branch mit path:line, dessen Inline-Kommentare und git log -L / blame; das Hauptticket und jeden Kommentar; die umgebenden Tickets (Parent / Epic, verknüpfte, Geschwister auf demselben Bildschirm oder API und Tickets, die die Commit-Nachrichten nennen); Regressionsergebnisse; und den Designknoten. Zitieren Sie, was neben der Feststellung gelesen wurde. Eine Frage, die die Quellen bereits beantworten, ist eine Feststellung mit ihrer Quelle, keine Frage.

Produkt-Klon fehlt oder ist nicht lesbar (die {MONOREPO}-Prüfung in dependencies.md schlägt fehl): stoppen Sie den Review nicht und überspringen Sie die Code-Ebene nicht stillschweigend. Schreiben Sie Code nicht geprüft — kein Klon neben jede Frage, die die Code-Ebene beantwortet hätte, führen Sie den Durchlauf mit den verbleibenden Quellen fort und präsentieren Sie eine solche Frage niemals als durchlauf-abgeschlossen — sie geht mit diesem Hinweis zu Schritt 4.

Ausgabe pro Element: die Feststellung (oder die verbleibende Frage) + die zitierte Quelle mit ihrem Speicherort (path:line, Ticket-Key + Kommentar, Regressionszeile, Designknoten) oder der Code nicht geprüft — kein Klon-Hinweis, wenn die Code-Ebene nicht ausgeführt werden konnte.

Gehe zurück: Eine Frage, die der Durchlauf beantwortet, kehrt zu Schritt 2 oder 3 als belegte Feststellung zurück; nur eine Frage, die keine Quelle beantwortet, geht zu Schritt 4 als „mit Entwickler/PO bestätigen“.

Schritt 4 — Bericht „Gut“ vs. „Verbesserungswürdig“ [mittlere Freiheit]

Zwei kurze Listen, jeder Aufzählungspunkt verankert mit einer Zeilen-ID, AC-ID oder zitiertem Text — niemals eine unverankerte Meinung.

**Gut**
- {Feststellung, mit TC/AC-ID oder Zitat}

**Verbesserungswürdig**
- {Feststellung, mit TC/AC-ID oder Zitat}
  → Vorschlag: {Wie zu beheben}

Jeder „Verbesserungswürdig“-Aufzählungspunkt trägt eine „→ Vorschlag:“-Zeile, die sagt, wie man es behebt. Ein Problem ohne Lösung lässt den TC-Autor raten. Jeder Vorschlag muss aus einer Quelle stammen, niemals ein erfundener Wert:

Aus den eigenen Daten der Zeile berechnet: wenn die Testdaten bereits die Eingaben enthalten, arbeiten Sie den Wert aus und geben Sie ihn an (z. B. die erwartete Reihenfolge mit jedem berechneten Score). Zeigen Sie die Zahlen, damit der Autor sie überprüfen kann.
Aus dem Wortlaut der AC/EC übernommen: z. B. ersetzen Sie die falsche Bedingung durch den eigenen Ausdruck der AC oder fügen Sie die fehlende Erwartetes-Ergebnis-Klausel unter Verwendung des eigenen Textes der AC hinzu.
Keine Quelle gibt den Wert (ein Schwellenwert, eine Zählung oder ein Zeitpunkt, den das Ticket nie angibt): schlagen Sie vor, den Wert hinzuzufügen, und sagen Sie, wer ihn bestätigt („Zählung mit Entwickler/PO bestätigen“). Erfinden Sie niemals eine Zahl.

Halten Sie jeden Aufzählungspunkt prägnant. Der Vorschlag sagt, was geändert werden soll, nicht eine umgeschriebene Zeile. Wenn der Benutzer bittet, den Umfang einzugrenzen (z. B. „alles zu X weglassen“), generieren Sie die Liste aus den Schritten 2–3 neu, wobei diese Kategorie entfernt ist — bearbeiten Sie nicht reaktiv Prosa von Hand, da dieselbe Kategorie sonst beim nächsten Mal anders formuliert wieder auftauchen würde.

Sprache: Standardmäßig die Sprache des Tickets / des TC-Dokuments verwenden. Gemischt = die AC/EC des Tickets und das TC-Dokument sind in verschiedenen Sprachen geschrieben → fragen Sie den Benutzer einmal, in welcher Sprache der Review verfasst werden soll. Helix-Menüs und Intake-Fragen bleiben auf Englisch gemäß user-communication.md; der Review-Inhalt selbst folgt der Sprache des Zieldokuments, dieselbe Ausnahme, die dieses Dokument bereits trägt.

Veröffentlichen Sie den Review im Chat, bevor Sie Schritt 5 senden — eine externe Nachricht kann nicht wie eine Chat-Nachricht rückgängig gemacht werden. Die Schritt-5-Thread-Frage ist die Freigabe; fügen Sie keine separate „Senden?“-Frage hinzu.

Schritt 5 — TC-Review-Kanal des Projekts benachrichtigen [geringe Freiheit]

Jede Ausführung sendet den abgeschlossenen Review an den TC-Review-Kanal des Projekts. Fragen Sie, in welchem Thread die Benachrichtigung veröffentlicht werden soll.

QA-Abschluss (obligatorisch vor „erledigt“) [geringe Freiheit]

Ein abschließender Lauf von qa-gate.md.

Skill-Zusammensetzung

tc-review-workflow — dieser Workflow

Nicht im Umfang

Neue Testfälle entwerfen → tc-fe-prep-workflow / tc-api-prep-workflow
Ein Ticket ausführen → testing-ticket-workflow
Aufgezeichnete Evidenz-Clips überprüfen → review-result-workflow
Einen Fix erneut testen → retest-bug-workflow

MUSS / NIEMALS

MUSS

shared-preamble.md und shared-must-never.md befolgen.
Beide Quellen wörtlich laden.
Die Fortschritts-Checkliste kopieren und abhaken.
Jede Feststellung mit zitierten Quellen auf beiden Seiten untermauern.
Schritt 3b durchführen, bevor eine Frage an PO/Reporter geht.
Einen Vorschlag für jeden „Verbesserungswürdig“-Punkt geben.
Vor dem externen Senden im Chat veröffentlichen.

NIEMALS

Testfälle entwerfen oder bearbeiten.
Eine Meinung ohne Zitat aus dem Ticket oder TC-Dokument äußern.
Eine Quelle aus dem Gedächtnis paraphrasieren.
AC/EC-Bezeichnungen erfinden.
Durchgestrichene AC/EC erwähnen.
Geschäftsregeln oder Kommentare, die keiner AC/EC widersprechen, als Feststellung melden.
Einen Wert erfinden, wenn die Quelle keinen angibt.
Einen stillen Fehler ignorieren (TC oder Ticket lädt nicht vollständig).

Zu lesende Dateien

Abhängigkeiten

{MONOREPO} muss auf ein gültiges Produkt-Klonverzeichnis verweisen (siehe dependencies.md).
Jira-MCP mit Lese-/Schreibzugriff auf das Projekt-Ticket.
Lesezugriff auf das TC-Dokument (Google Sheets, Dateisystem oder Repository).
Benachrichtigungskanal für TC-Review (Slack, Teams oder ähnlich).

Thitic9203/tc-review-workflow

Was ist tc-review-workflow?

In Ihrer bevorzugten KI fragen

Dokumentation