konzept vertraulich owner: matus
Testmanagement anschließen — der fachliche Testfallkatalog für Fachowner
Testmanagement anschließen — der fachliche Testfallkatalog für Fachowner
Status: entschieden (2026-08-12, Nutzerentscheidung) · Adressat: Product Owner + Fachowner · Art: Scope-Erweiterung, keine fachliche Korrektur
Auftrag war: Fachowner sollen den fachlichen Testfallkatalog sehen und einzelne Fälle mit
Mock-Daten starten können — nicht nur Entwickler per mvn test. Vorbild aus den Schwesterprodukten
(C:\dev\eventim\): evepop hat genau das, gebaut auf dem generischen, produktneutralen
zwirn-testmanagement-service. evenews hat eine andere, engere Lösung (freie Mock-Verwaltung ohne
Katalog).
Korrektur 2026-08-14: Hier stand bis dahin,
eimrhabe "nur toten, geerbten UI-Code ohne eigenes Backend". Das war falsch — Recherche inC:\dev\eventim\eimr(Nutzer-Anstoß, Screenshot-Vergleich) zeigt, dasseimr-ui/src/domains/demolive gegen genau denselbenzwirn-testmanagement-servicespricht (TestGroupResource/TestSubgroupResource/TestCaseResource/TestRunResource,C:\dev\zwirn\test\testmanagement-service) — nur eben mit einem viel reicheren, selbst gebauten Frontend-Slice davor: dreistufige Gruppierung mit Card-Grid + Akkordeon, CSV-Export und ein BPMN-Prozessdiagramm mit Testfall-Coverage-Highlighting (@zwirn/bpmn-Vorlaeufer, vor der Extraktion ins gemeinsame Paketprocess-hub-bpmn-web).eimr-test-servicesteuert dazu nur den Mock-Mail-Trigger bei. Der tatsaechliche Unterschied zu tuxametrics war also nicht Backend vs. kein Backend, sondern Umfang des Frontend-Slice — inzwischen mitTestGruppenUebersichtPage/TestGruppeDetailPage/GoldPathDiagrammnachgezogen (siehe unten).
Dieselbe Kategorie wie audit-feedback-processhub-integration.md:
Zwirn-ADR-0006, dritter Wiederverwendungsmechanismus (Docker-Service, betrieben statt importiert). Kein
neues ADR nötig — auch Audit/Feedback bekamen keins, nur diesen Dokumenttyp.
Was angeschlossen wurde
| Baustein | Art | Herkunft | Was tuxametrics davon hat |
|---|---|---|---|
zwirn-testmanagement-service |
fertiges Docker-Image | ../../../zwirn/test/testmanagement-service |
Produktneutraler Katalog (TestGroup→TestSubgroup→TestCase) + TestRun-Ausführungsprotokoll |
tuxametrics-ui/src/domains/testfaelle |
eigener Domain-Slice | neu, hier gebaut | Übersicht + Detailseite des Katalogs — kein fertiges @zwirn/testmanagement-Frontend-Paket existiert (anders als bei Audit/Feedback/BPMN) |
scripts/migrate-testfaelle.mjs |
einmaliges Skript | neu, hier gebaut | Trägt die 63 Fälle aus documentation/testfaelle-gold-path.md in den Katalog ein |
Nicht angeschlossen: ein eigener Trigger-Service (wie evepop-test-management-service). evepops
Mock-Szenario (Mail senden) brauchte einen neuen Mechanismus; tuxametrics' Mechanismus (synthetischen
Fall anlegen) existiert bereits als POST /api/txm/v1/tenants/{tenantKey}/demo/referenzfall
(ReferenzfallResource/ReferenzfallService) und wird unverändert wiederverwendet.
Die vier Entscheidungen
1. Kein neuer tuxametrics-Trigger-Service
Das Frontend (shell/TestfallAusfuehren.tsx) ruft direkt den bestehenden Referenzfall-Loader auf und
protokolliert das Ergebnis als TestRun. Eine zweite, tuxametrics-eigene Quarkus-Ressource nur für
diesen einen Aufruf wäre eine Dopplung ohne Nutzen.
2. Kein neuer txm.*-Capability-Key
txm.demo.load gated den Trigger bereits (unverändert). Katalog-Lesen/-Schreiben und
Testlauf-Protokoll werden von zwirn-testmanagement-services eigenen, produktneutralen Capabilities
gegated (zwirn-testmanagement.catalog.read/.write, .run.read/.create/.write, allowedActors
unrestringiert). Diese fünf Keys sind zusätzlich in tuxametrics-platform-services bestehenden
Demo-Grant-Mechanismus aufgenommen (CapabilityRegistrar.seedDemoGrants, Schalter TXM_DEMO_GRANTS,
unverändert Default false) — kein neuer Mechanismus, nur eine erweiterte Liste.
3. Das Migrationsskript ist einmalig, kein Dauer-Importer
Zwirn-ADR-0019
hält den Katalog-Service ausdrücklich produktneutral, ohne eigene Seed-Logik. scripts/migrate-testfaelle.mjs
läuft einmal gegen den frisch integrierten Service und trägt scripts/testfaelle-katalog.json ein
(1:1 aus documentation/testfaelle-gold-path.md übertragen). Danach ist die REST-API des Service der
Pflegeweg für neue oder geänderte Fälle, nicht das Skript.
Zwei Felder blieben dabei bewusst leer: TestCase.testStep/.expectedResult (das Quellmaterial
trennt Testschritt und erwartetes Ergebnis nicht — anders als evepops TF-PRC-Katalog; sie zu erfinden
wäre eine Struktur, die die Quelle nicht hergibt) und TestSubgroup.preconditions (aus demselben
Grund). FACH-Referenz und die "im Code"-Spalte aus der Quelle wandern stattdessen als Klartext in
TestCase.description.
4. "Testfälle" ist eine fachliche Hauptsektion, keine System-Sektion
Anders als Audit/Process-Hub (Footer, für Entwicklung/Betrieb) stand "Testfälle" zunächst in der Haupt-IconRail, weil der Auftrag ausdrücklich Fachowner als Zielgruppe nennt.
Überholt seit 2026-08-13. Die IconRail selbst gibt es nicht mehr — die Navigation wurde auf eine einzige, immer sichtbare Sidebar umgestellt (Muster aus eimr/evenews). Im Zug dessen wurde "Testfälle" doch in die untere "Technische Daten"-Gruppe verschoben (Produktentscheidung), zusammen mit Protokoll/Prozesse. Das widerspricht Punkt 4 nicht der Sache nach — Fachowner erreichen die Seite weiterhin ohne Umweg, nur nicht mehr als eigener oberster Menüpunkt. Details:
tuxametrics-ui/src/nav/navConfig.ts.
Der Preis, ungeschönt
| vorher | nachher | |
|---|---|---|
| Container im Stack | 17 | 19 |
| Postgres-Instanzen | 7 | 8 |
| Host-Ports | — | + 8127 (Service), 5527 (DB) |
| npm-Dependencies | — | keine neuen (kein @zwirn/testmanagement-Paket — der Slice ist Handarbeit gegen die REST-API) |
| Frontend-Aufwand | — | ein kompletter neuer Domain-Slice statt eines fertigen Pakets, weil keins existiert |
Was danach noch offen ist
| Punkt | Warum offen |
|---|---|
Aktualisiert 2026-08-15 (abends). Bis dahin hatte tuxametrics genau einen ausgearbeiteten synthetischen Referenzfall (Konstellation 2 = TC-AUS-013). Seither sind es drei: dazugekommen sind Konstellation 4 (TC-AUS-008, kritischer Kaliumwert mit Hämolysehinweis) und Konstellation 5 (TC-AUS-009, ohne). MOCK_SZENARIEN in shell/TestfallAusfuehren.tsx bildet Testfall → Szenarioschlüssel ab; „Ausführen" lädt jetzt den zum Testfall gehörenden Fall statt überall denselben. Begründung der Auswahl: demo-nav-bundling.md, Abschnitt „Dritte Iteration". Die übrigen 60 zeigen unverändert ehrlich "Kein Mock-Szenario hinterlegt" statt eines Buttons, der ins Leere liefe. Weitere Szenarien auszuarbeiten bleibt fachlicher Aufwand (neue init-bundle-Datensätze je Fall), kein Verdrahtungsproblem — kein Endzustand. |
|
| Katalog seit v1.1, nicht auf Backlog v1.2 nachgezogen. | documentation/testfaelle-gold-path.md selbst nennt das offen: der Quellkatalog ist inzwischen auf 116 Fälle in 8 Gruppen/27 Untergruppen gewachsen. Der migrierte Katalog trägt entsprechend denselben veralteten Stand — siehe testabdeckung-gold-path.md. |
TestCase.status bleibt TODO für alle 63. |
So steht es in der Quelle; BUILT würde Implementierung behaupten, was das Repo an anderer Stelle ausdrücklich vermeidet (siehe documentation/testfaelle-gold-path.md). Wer einen Fall tatsächlich baut, müsste den Status über die REST-API des Service pflegen — dafür gibt es noch keine Oberfläche, nur die API. |
| Keine Admin-Oberfläche für den Katalog selbst. | Gruppen/Untergruppen/Fälle anlegen oder ändern geht nur über die REST-API (zwirn-testmanagement.catalog.write), nicht über die tuxametrics-UI — die zeigt nur lesend. |
Kein Testfall trägt bpmnPath. |
GoldPathDiagramm (2026-08-14, Nachzug an eimr) zeigt das eine Gold-Path-Prozessdiagramm (tuxametrics-auswertung.bpmn20.xml, wiederverwendet aus dem bereits vorhandenen @zwirn/bpmn-Paket), aber OHNE Coverage-Hervorhebung: keiner der 63 migrierten Fälle hat ein bpmnPath-Feld gesetzt, und eine Zuordnung Testfall→BPMN-Element zu erfinden wäre genau die Art erfundener Vollständigkeit, die dieses Repo sonst vermeidet. Die acht Testgruppen entsprechen zwar plausibel den Lanes/Tasks des Diagramms (scope-gate→Task_scope, fachliche-auswertung→Task_eval, …), aber das ist Beobachtung, keine geprüfte Zuordnung — bis das jemand fachlich verifiziert und je Testfall eintraegt (zwirn-testmanagement.catalog.write), bleibt die Hervorhebung aus. |
Unangetastet geblieben: TUXAMETRICS_REGULATORIK_EINSTUFUNG und TUXAMETRICS_PILOT_BETRIEBSMODUS
stehen weiterhin auf UNGEKLAERT; RegulatorikGuard ist nicht berührt. Keine neue Fachzahl, kein
neuer Enum-Wert im Domänenmodell.