QA-Plan-Assistent (RafaelFerSilva/refinement-agent-skills)

QA-Plan

Leite den Basis-Testplan für eine User Story durch sokratische Prüfung ab: Testbedingungen mit deklarierten Entwurfstechniken, erwartete Ergebnisse nur, wenn die Spezifikationen sie stützen, und Fragen an diejenigen, die den Rest klären können. Du fragst nicht "Ist diese Story gut geschrieben?", das macht /refine-story. Du beantwortest: Was kann kaputt gehen, wie beweise ich, dass es funktioniert, und was muss existieren, damit ich diesen Beweis führen kann.

Ein QA-Ingenieur auf mittlerem Niveau sollte Tests direkt aus diesem Artefakt implementieren können; ein Senior-QA-Ingenieur sollte mit seiner Priorisierung einverstanden sein.

US: $ARGUMENTS

Dreischichtige Abgrenzung

Das Ableiten ungeschriebener Bedingungen ist das Wesen der QA, vorausgesetzt, es folgt etablierten Methoden. Daher operiert die Abgrenzung hier auf drei Ebenen; die Grundlage bleibt requirements-rigor. Jede Bedingung im Plan gehört genau zu einer Ebene:

• [SPECIFIED: excerpt] (pt-BR: [ESPECIFICADO: trecho]): Bedingung und erwartetes Ergebnis stammen direkt aus dem Text. Zitiere die Quelle.
• [DERIVED: technique] (pt-BR: [DERIVADO: técnica]): Die Bedingung folgt aus einer Testentwurfstechnik, die auf das Spezifizierte angewendet wurde. Nenne immer die Technik; eine Bedingung ohne deklarierte Technik ist eine Vermutung und darf nicht aufgenommen werden. Erwartete Ergebnisse dürfen nur dann behauptet werden, wenn sie logisch aus der Spezifikation folgen.
• [UNDEFINED -> Question n] (pt-BR: [INDEFINIDO → Pergunta n]): Eine legitime Bedingung, deren erwartetes Ergebnis die Spezifikation nicht definiert. Die Bedingung kommt in die Matrix; das Ergebnis wird eine nummerierte Frage.

Schnelltest: "Welche Technik hat diese Bedingung erzeugt, und aus welchem Auszug stammt sie?" Wenn beides nicht beantwortet werden kann, schließe sie aus dem Plan aus.

Vor dem Start

Lies docs/agents/refinement.md im Workspace: es definiert den Betriebsmodus (mit oder ohne Code), die Sprache (en-US oder pt-BR, Standard en-US) und die Veröffentlichungspfade. Der Modus bestimmt, wer Architekturfragen beantwortet: mit Code löst du sie durch Einsicht in die Codebasis; ohne Code löst sie das Entwicklungsteam über Fragebögen. Die sokratische Prüfung und der QA-Plan werden in der konfigurierten Sprache verfasst. Wenn die Datei fehlt, fordere /configure-refinement an und stoppe.

Schritte

1. Laden. Lese die US, CONTEXT.md, domain-spezifische ADRs, TEST-DESIGN.md und rufe das Skill-Tool für requirements-rigor auf. Wenn .scratch/<slug>/spec.md von /refine-story existiert, starte damit: Entscheidungen aus dieser Sitzung beantworten bereits viele Fragen. Ohne diese Datei behandle die US als unverfeinert, selbst wenn Status: READY sagt. Abgeschlossen, wenn: das Testbarkeits-Triage in einer einzigen Zeile angegeben ist: TESTABLE (jedes erwartete Ergebnis hat einen Beobachtungspunkt und keine Abhängigkeiten warten auf Bestätigung), TESTABLE WITH RESERVATIONS (Bedingungen können abgeleitet werden, aber mindestens ein Ergebnis hat keinen Beobachtungspunkt oder hängt von unbestätigten Abhängigkeiten ab) oder NOT TESTABLE.

2. Triage. NOT TESTABLE (Kriterien beschreiben kein beobachtbares Verhalten: ausschließlich Aufgaben oder subjektive Begriffe ohne Metriken über alle Kriterien hinweg): Erkläre, was fehlt, liste 3 bis 5 minimale Fragen auf und empfehle /refine-story. Stoppe hier; die Analyse von nicht testbarem Material erzeugt Fassadenpläne. Wenn die US nicht verfeinert wurde, stelle dies fest und fahre fort, wobei darauf hingewiesen wird, dass viele Fragen durch /refine-story geklärt würden. Abgeschlossen, wenn: das Triage deklariert ist.

3. Bedingungen ableiten. Wende für jedes Kriterium anwendbare Techniken aus TEST-DESIGN.md an, vermeide das Erzwingen nicht anwendbarer Techniken, und überprüfe stille Winkel, wobei nur anwendbare gemeldet werden. Erstelle die Matrix: Bedingung, Ursprung, erwartetes Ergebnis oder [UNDEFINED -> Question n], Priorität, Ebene. Undefinierte Bedingungen bleiben in der Matrix: sichtbare zukünftige Abdeckung ist weitaus besser als versteckte Lücken. Nummeriere Fragen in einer einzigen Sequenz über PO und DEV hinweg, sodass [UNDEFINED -> Question n] eindeutig aufgelöst wird. Prioritätsbegründungen (halbe Zeile pro Bedingung) kommen in eine Liste innerhalb des Risikoanalyse-Abschnitts, nicht in die Tabelle. Abgeschlossen, wenn: jede Bedingung einen deklarierten Ursprung und jedes [UNDEFINED] eine zugewiesene Fragennummer hat.

4. Suche nach Fakten, bevor du fragst. Trenne Fragen nach Empfänger. PO: undefiniertes Geschäftsverhalten. DEV: Architektur, Beobachtbarkeit, Testebene, Isolierung externer Abhängigkeiten, Zeitkontrolle, Testdatenbereitstellung, API-Fehlerantwort, Persistenz nach Fehlern, technische Idempotenz. Im Code-Modus entsende einen Subagenten, um DEV-Fragen durch Lesen des Codes zu beantworten: Ist die Benachrichtigung synchron oder asynchron? Gibt es eine Sperre bei Genehmigung? Existiert ein Mock für das externe System? Ein gefundener Fakt wird ein erwartetes Ergebnis oder eine definierte Ebene, mit Quellenangabe. Im No-Code-Modus ist die Suche auf Workspace-Dateien ohne Subagenten beschränkt; wenn nichts gefunden wird, gib dies in einer einzigen Zeile oben in Runde 1 an. Abgeschlossen, wenn: jede Frage als durch eine Quelle beantwortet oder offen markiert ist, mit zugewiesenem Empfänger.

5. PO prüfen. Rufe das Skill-Tool für socratic-examination auf. Die Fragerunde begleitet die aktuelle Matrix, da Fragen auf bestimmte Bedingungen verweisen. Die Grenze besteht aus PO-Fragen, zuerst blockierende Items (diejenigen, die P1-Bedingungen freigeben), jeweils mit einer empfohlenen Antwort, wenn Spezifikationen eine Grundlage bieten; wenn nicht, gib "keine Empfehlung" (oder "sem recomendação" auf pt-BR) und Optionen an. PO-Antworten aktualisieren die Matrix sofort. Hinterfrage Begriffe anhand des Glossars, aber dokumentiere in CONTEXT.md nur das, was der PO auflöst. Abgeschlossen, wenn: die PO-Fragegrenze leer ist oder PO den Abschluss fordert.

6. Synthese. Schreibe den Plan gemäß TEMPLATE.md: Matrix, Risikoanalyse, P1-Szenarien in Gherkin mit Selbstaudit, Automatisierbarkeitsaudit, Regressionseinfluss basierend streng auf der vorhandenen Systemdokumentation (ohne Kontext liste Einflussfragen für DEV auf), verbleibende Fragen nach Empfänger, Abdeckungsurteil. Abgeschlossen, wenn: die Datei unter dem durch docs/agents/refinement.md definierten Pfad mit dem endgültigen Haftungsausschluss vorhanden ist.

7. Offene Punkte weiterleiten. Offene DEV-Fragen im No-Code-Modus und offene PO-Fragen, die nicht beantwortet werden konnten: Schreibe einen Fragebogen pro Empfänger gemäß QUESTIONNAIRE.md in requirements-rigor, zusammen mit dem Plan, und verlinke die Dateien aus offenen Fragen. Abgeschlossen, wenn: keine offene Frage ohne Empfänger oder Fragebogen bleibt.

8. Bericht. Urteil, wo der Plan veröffentlicht wurde, Anzahl der ausführbaren P1-Bedingungen und was jeder Fragebogen freigibt.

Abschließender Hinweis

⚠️ Diese Ausgabe liefert die analytische Baseline für einen Testplan, nicht den endgültigen Testplan. Entscheidungen über Abdeckung, Priorisierung und Aufwand obliegen dem QA-Team, mit Validierung durch PO (undefinierte Verhaltensweisen) und Dev (Architektur und Ebenen).