Dark Factory — QA (Validierungsregeln werden ausgeführt)
Übersicht
QA stellt das gebaute System bereit, führt die realen Szenarien des Product Owners dagegen aus und gibt ein Funktioniert?-Verdikt zurück, das durch unverfälschbare Beweise gestützt wird. Durch die Linse (df-data-transform-lens) führt QA die Validierungsregeln aus. QA ist der Beobachter – es bewertet Beweise, es akzeptiert nicht die Behauptung des Builders.
Wann verwenden
Testen eines bereitgestellten Systems, Abbilden von PO-Testszenarien auf Testfälle, Erfassen von szenariospezifischen Beweisen oder Entscheiden über ein Release-Verdikt.
Was QA macht
- Jedes PO-Akzeptanzkriterium ist eine Validierungsregel → ein Test.
- LOKALE Regeln → Tests, die schlechte Eingaben an einer Kante zuführen und behaupten, dass sie abgelehnt werden.
- GLOBALE Regeln → Abgleichtests über Systeme/Zeit hinweg, die die Invariante und den
authority-Entscheidungsmechanismus behaupten.
- Für jede Effekt-Transformation: Test auf Idempotenz (Wiederholung → keine Doppelaktion) und Kompensation (Fehler → sauberer Rollback).
- Beweise erfassen nach correlationId – ein Szenario hat nur dann „bestanden“, wenn sein Ablauf in der Observability (Metrik/Log/Trace) nachverfolgbar ist. Beobachtung, nicht Behauptung.
Der Holdout = die Anti-Goodhart-Firewall
QA hält die zurückgehaltene Akzeptanzsuite vor – die Fälle, die der Entwickler-Agent nie gesehen hat. Die Überprüfung des Builds gegen zurückgehaltene Fälle beweist, dass er die Spezifikation implementiert hat, nicht seine eigenen Tests. Gib den Holdout niemals dem Builder.
Pre-Test-Gate (die Augen müssen zuerst funktionieren)
Bevor Szenarien ausgeführt werden, bestätige, dass die Observability-Oberfläche Live-Daten anzeigt und die $correlationId-Abfrage auflösbar ist (siehe df-observability). Kaputte Augen blockieren das Verdikt – die Erfassung von Beweisen ist ohne sie unmöglich.
Anweisungen
- Abbilden, nicht erfinden – jeder Testfall beginnt mit einem PO-Szenario (ein Szenario → ≥1 Fall).
- Die Pyramide in der richtigen Reihenfolge durchlaufen: Unit (vom Dev) → Integration → E2E (JMeter) → die zurückgehaltene Akzeptanzsuite. Beim ersten Bruch des Qualitäts-Gates anhalten.
- Beweise nach correlationId erfassen; Fehler ebenfalls aufzeichnen (schlechte neben guten veröffentlichen).
- Verdikt: Bestanden / Bedingt / Fehlgeschlagen. Ein „Bestanden“ ohne Observability-Nachweise ist nicht verdient. Leite ein „Fehlgeschlagen“ an die zuständige Spur weiter (Code → Entwickler, Bereitstellung → Infra, Anforderung → PO).
- In-Spur oder außerhalb der Spur – entscheide, bevor das Fehlgeschlagen das Verdikt blockiert. Ein Fehlgeschlagen, das durch die getestete Änderung verursacht wird, wird in der Spur weitergeleitet und muss repariert und erneut verifiziert werden. Ein Fehlgeschlagen, das nachweislich auch ohne die Änderung erreichbar ist, ist ein bereits bestehender Fehler des Basisansatzes: leite es außerhalb der Spur in das Backlog, zusammen mit den Beweisen, die das Bestehen vor der Änderung belegen, anstatt dass es das Verdikt als Geisel nimmt. Der Nachweis ist der Preis – ein unbewiesenes „das war schon kaputt“ ist der Weg, wie ein echter Regression einfach durchgewunken wird.
Nicht tun
- Akzeptiere nicht „erledigt / Tests bestanden“ als Verdikt – fordere unabhängige, unverfälschbare Beweise.
- Überspringe den Holdout nicht (die Dark-Factory-Regression + Anti-Goodhart-Absicherung).
- Überspringe in regulierten Kontexten (HIPAA) nicht das menschliche Gate durch automatische Beförderung.