# Beispiel: Assessment- und Release-Bericht

Version 1.0 · 13. Oktober 2026 · Wavect

Illustrativer Bericht für ein fiktives B2B-Terminprodukt. Die Einträge zeigen das Lieferformat und sind keine Testergebnisse eines Kunden.

## Auftrag und Prüfmethode

Einen vorhandenen Prototyp für den ersten Kundenpiloten vorbereiten und den Betrieb an das Kundenteam übergeben. Geprüft werden Buchungserstellung, Rollenrechte, Wiederholungsversuche und Wiederherstellung. Zwei synthetische Mandanten enthalten jeweils Administrator, Editor und Betrachter. Build A prüfen, reproduzierbare Befunde erfassen und vereinbarte Reparaturen in Build B mit denselben Testdaten nachprüfen.

## Release-Entscheidung

**Pilot zurückhalten, bis Wiederherstellungsprüfung OP-01 bestanden ist.** Rechte- und Retry-Reparaturen erfüllen im Beispiel die vereinbarten Nachprüfungen. Ein erfolgreicher Backup-Job allein belegt nicht, dass das übernehmende Team den Dienst wiederherstellen kann.

## Befunde und Nachprüfung

| ID | Schweregrad und Auswirkung | Reproduktion | Erwartung / Beobachtung in Build A | Abnahme und Status in Build B | Verantwortung |
| --- | --- | --- | --- | --- | --- |
| QA-01 | Hoch: Betrachter kann Buchung ändern | Als Betrachter von Mandant A dieselbe Änderungsanfrage wie ein Editor senden; Buchung neu laden | Erwartung: abgelehnt und unverändert. Beobachtung: Änderung akzeptiert | BESTANDEN: Betrachter abgewiesen, Buchung unverändert; Editor von A darf weiterhin ändern; Mandant B erhält keinen Zugriff | API-Engineer |
| QA-02 | Hoch: Wiederholung erzeugt zweite Buchung | Buchung senden, Antwort unterbrechen und mit derselben Anfrage-ID wiederholen | Erwartung: eine Buchung mit identischem Ergebnis. Beobachtung: zwei Buchungen | BESTANDEN: Wiederholung liefert ursprüngliches Ergebnis; zwei tatsächlich unterschiedliche Anfragen erzeugen weiterhin getrennte Buchungen | API-Engineer |
| OP-01 | Release-Blocker: Wiederherstellung nicht übergeben | Letztes synthetisches Backup in isolierter Umgebung mit den Zugängen des übernehmenden Teams wiederherstellen | Erwartung: lesbare Buchungen und dokumentierter Neustart. Beobachtung: Restore-Zugang und Verantwortlicher fehlen | BLOCKIERT: Zugang zuweisen, Restore ausführen, Testdatensätze vergleichen und Dauer gegen das vereinbarte Ziel messen | Plattform-Verantwortlicher |

Der Schweregrad folgt Nutzerwirkung und Wiederherstellbarkeit im vereinbarten Umfang, nicht dem Werkzeug, das den Fehler findet. Hohe Befunde verlangen vor diesem Piloten eine Reparatur oder eine ausdrücklich benannte Risikoentscheidung. Ein Release-Blocker verletzt die vereinbarte Freigabebedingung.

## Rescue-Entscheidung: behalten, härten, ersetzen

- **Behalten:** funktionierendes Buchungsmodell und Kalender-UI; nach jeder Reparatur mit den Testdaten prüfen.
- **Härten:** Backend-Berechtigungen und Deduplizierung von Anfragen. Reparaturen müssen Fehlerfälle und erlaubte Aktionen bestehen.
- **Ersetzen:** Deployment-Abhängigkeit vom Konto eines ausscheidenden Dienstleisters durch einen Release-Pfad im Kundenkonto. Diese Befunde verlangen keinen Neubau der Buchungsfunktion.
- **Reihenfolge:** Kundenzugang herstellen, QA-01 und QA-02 reparieren, nachprüfen und OP-01 vor der Pilotfreigabe abschließen. Aufwand und Preis folgen Repository-Prüfung und vereinbartem Reparaturumfang.

## Takeover-Abnahme

Das übernehmende Team muss von einem festgelegten Commit bauen, nach Staging deployen, den kritischen Buchungsablauf prüfen, Monitoring lesen und die Wiederherstellung ausführen können. Dokumentiert werden Repository- und Umgebungsverantwortung, Secret-Speicherorte ohne Secret-Werte, Deployment und Rollback, Backup-Aufbewahrung und Support-Eskalation. Übernommene Zugangsdaten erst rotieren, wenn die geprüften Ersatz-Zugänge funktionieren.

Quellcode, Infrastrukturkonten und Befundregister bleiben beim Kunden. Jeder offene Punkt braucht Verantwortlichen, nächste Prüfung und Entscheidungsdatum. Die Übergabe endet, wenn das neue Team die vereinbarten Betriebsabläufe demonstriert, nicht beim Versand eines Dokuments.

## Evidenzregister und verbleibender Umfang

Commit-IDs von A und B, Testdatenbeschreibung, bereinigte Anfrage-/Antwortprotokolle für QA-01 und QA-02, Regressionsergebnis und Restore-Protokoll von OP-01 beilegen. Evidenz-IDs zwischen Befund, Reparatur und Nachprüfung beibehalten. Je Ergebnis Prüfer, Datum und Umgebung erfassen.

Lastkapazität, Zahlungsintegration, mobiler Offline-Betrieb und produktive Kundendaten liegen außerhalb dieses Beispiels. BESTANDEN gilt für die bezeichnete Prüfung und Version. Der Bericht endet mit der nächsten Release-Entscheidung und ihrem Verantwortlichen.