Euer erster Prüfbericht
Zuletzt aktualisiert: 2026-07-16Lesezeit ca. 3 Min.
Ein erster Prüfbericht ist ein begrenzter Record eines echten Changes: Auftrag, unveränderlicher Change-Verweis, exakte Checks und beobachtete Ergebnisse, bekannte Auslassungen, Reviewer und Entscheidung. Nützlich ist er durch explizite Evidenz und Grenzen-nicht, weil er vollständig klingt.
Inhalt
Einen echten Change wählen und die Grenze definieren
Startet mit einem wiederkehrenden Change, den ein Reviewer überblicken kann. Schreibt vor dem KI-unterstützten Run Ziel, zulässige Pfade, Ausschlüsse und prüfbare Akzeptanzkriterien. So erhält der Reviewer eine von der generierten Implementierung unabhängige Referenz. BSI/ANSSI empfiehlt, generierten Quellcode zu prüfen und durch Entwickelnde reproduzierbar zu halten; die Leitlinie schreibt weder dieses Berichtsformat vor noch verspricht sie, ein erfasster Check mache Code korrekt.
- Auftrag definieren. Beobachtbares Ziel, Dateigrenzen und Ja/Nein-Akzeptanzkriterien vor der Ausführung festhalten.
- Beobachteten Change referenzieren. Unveränderlichen Commit oder Diff und tatsächlich geänderte Dateien erfassen.
- Unabhängige Checks ausführen. Exakte Befehle, Outcomes, Zeitpunkte und vorhandene Receipts erfassen-einschließlich Fehlern und ausgelassenen Checks.
- Unsicherheit benennen. Nicht getestete Bereiche, Gründe und ausstehendes Review sichtbar machen.
- Entscheidung erfassen. Reviewer, Rolle, Entscheidung und Zeitpunkt nennen; keine nicht vorhandene Unabhängigkeit andeuten.
Eine Vorlage nutzen, die Evidenz nicht imitiert
Das Muster enthält absichtlich Platzhalter statt erfolgreicher Ergebnisse. Kopiert nur das Schema und füllt es nach einer echten Ausführung aus Befehlsausgabe und unveränderlichen Repository-Verweisen. Ein vollständig klingender synthetischer Bericht ist schlechter als ein kurzer Record, der ehrlich sagt, dass ein Check nicht ausgeführt wurde.
Illustrative Vorlage - kein echter Prüfbericht
pruefbericht-vorlage.mdtext/markdown
Illustratives Muster · keine Evidenz# Prüfbericht · <Change-ID> · <Datum>
## Auftrag
Ziel: <beobachtbares Ziel>
Grenzen: <zulässige Pfade und Ausschlüsse>
Kriterien: <prüfbare Kriterien>
## Änderung
Commit/Diff: <unveränderlicher Verweis>
Dateien: <beobachtete Liste>
## Validierung
Befehl: <exakter Befehl>
Ergebnis: <bestanden | fehlgeschlagen | nicht ausgeführt>
Receipt/Log: <Verweis oder "nicht vorhanden">
## Offene Grenzen
- <nicht geprüfter Bereich und Grund>
## Entscheidung
Reviewer: <Name/Rolle>
Entscheidung: <freigegeben | abgelehnt | Änderungen verlangt>
Zeitpunkt: <ISO-8601>Jedes Feld auf seinem tatsächlichen Evidenzniveau lesen
Ein Auftrag dokumentiert Absicht; er validiert nicht das gewählte Ziel. Ein Commit identifiziert eine Änderung; er belegt nicht die Autorschaft jeder Zeile. Ein Test-Receipt zeigt das beobachtete Ergebnis eines Befehls in seiner Umgebung; es deckt nicht jede Security-, Qualitäts- oder Compliance-Eigenschaft ab. Eine Review-Entscheidung dokumentiert Verantwortung; sie ist nicht automatisch unabhängige Assurance.
Was ein Artefakt belegt - und was nicht
| Auftrag | Änderung | Validierung | Entscheidung | |
|---|---|---|---|---|
| Kann belegen | Beabsichtigtes Ziel, Scope und KriterienRedaktionelle Evidenzgrenze · 2026-07-16Gilt nur bei vollständigem, unverändertem und prüfbarem Record. | Zuordnung zu konkretem Diff/CommitRedaktionelle Evidenzgrenze · 2026-07-16Gilt nur bei vollständigem, unverändertem und prüfbarem Record. | Welcher Befehl welches Ergebnis zu welchem Zeitpunkt lieferteRedaktionelle Evidenzgrenze · 2026-07-16Gilt nur bei vollständigem, unverändertem und prüfbarem Record. | Wer welche Entscheidung dokumentierteRedaktionelle Evidenzgrenze · 2026-07-16Gilt nur bei vollständigem, unverändertem und prüfbarem Record. |
| Belegt nicht | Nicht, dass das Ziel richtig gewählt wurdeRedaktionelle Evidenzgrenze · 2026-07-16Erfordert separate Prüfung oder zusätzliche Evidenz. | Nicht Autorschaft oder FehlerfreiheitRedaktionelle Evidenzgrenze · 2026-07-16Erfordert separate Prüfung oder zusätzliche Evidenz. | Nicht vollständige Security, Qualität oder ComplianceRedaktionelle Evidenzgrenze · 2026-07-16Erfordert separate Prüfung oder zusätzliche Evidenz. | Nicht unabhängige Assurance oder zukünftige KorrektheitRedaktionelle Evidenzgrenze · 2026-07-16Erfordert separate Prüfung oder zusätzliche Evidenz. |
Ein erster Bericht sollte
- Einen echten Change referenzieren
- Befehle und beobachtete Ergebnisse nennen
- Auslassungen sichtbar machen
- Reviewer und Entscheidung dokumentieren
Er sollte nicht behaupten
- Der Code sei fehlerfrei
- Jede Zeile stamme von einer bestimmten Person oder KI
- Security oder Compliance sei vollständig
- Ein einzelner Bericht beweise ROI
Erst nach Review des ersten Records wachsen
Prüft, ob Auftragsgrenze und Receipts reproduzierbar waren, Fehler sichtbar blieben und die Entscheidung später verständlich ist. Schärft die Vorlage, bevor ihr weitere Workflows hinzufügt. Um zu testen, ob die Praxis Rework oder Review-Aufwand verändert, definiert eine Baseline mit den Verification-Debt-Maßen und vergleicht einen begrenzten Zeitraum. Ein Bericht kann keinen ROI belegen.
Reality Graph kann Auftrag, Run, Validierung und Entscheidung im bestehenden Workflow aufbewahren. Dieselbe Grenze gilt: Generierte Records sind nur Evidenz, wenn sie echte Ausführung referenzieren und Fehler, Ausschlüsse und Review-Entscheidungen erhalten. Wie diese Records zu einem einzigen Ergebnis zusammenlaufen und warum ein Run trotz grüner Tests blockiert bleiben kann, steht unter den Regeln für das Prüfergebnis.
FAQ
- Wie schnell kann ein Team den ersten Prüfbericht erstellen?
- Die Dauer hängt von Change, vorhandenen Checks und Reviewtiefe ab. Startet statt mit einem Zeitversprechen mit einem begrenzten Change. Ein nützlicher Bericht erfasst Auftrag, unveränderlichen Change-Verweis, exakte Validierungsbefehle und beobachtete Ergebnisse, Auslassungen, Reviewer und Entscheidung.
- Was ist der kleinste sinnvolle erste Schritt?
- Schreibt vor einem echten KI-unterstützten Change einen Auftrag: Ziel, zulässige Pfade, Ausschlüsse und prüfbare Akzeptanzkriterien. Hängt nach dem Run den tatsächlichen Diff oder Commit und die Validierungs-Receipts an. Tragt keine bestandenen Ergebnisse vorab ein.
- Brauchen wir zum Start ein neues Tool?
- Nein. Ein Markdown-Record und bestehende CI können für einen ersten begrenzten Workflow genügen. Tooling wird nützlich, wenn es Provenienz, Receipts und Entscheidungen zuverlässig erfasst, ohne Fehler zu verstecken oder den Evidenzstandard zu verändern.
- Wer sollte den Bericht verantworten?
- Der Change-Owner erfasst Auftrag und Ausführungsfakten; der benannte Reviewer dokumentiert die Entscheidung. Für höheres Risiko kann ein Control-Owner hinzukommen. Ein Bericht darf keine unabhängige Assurance andeuten, wenn dieselbe Person alle Schritte ausgeführt und freigegeben hat.
- Was kann ein Prüfbericht beweisen?
- Er kann belegen, dass ein benannter Befehl für einen referenzierten Change zu einem Zeitpunkt ein erfasstes Ergebnis lieferte und ein Reviewer eine Entscheidung dokumentierte. Allein beweist er weder Fehlerfreiheit noch vollständige Security oder Compliance, Autorschaft jeder Zeile oder zukünftige Korrektheit.
- Wie wächst ein Bericht zur Teampraxis?
- Prüft zuerst, ob der erste Record vollständig und nützlich war, schärft Definitionen und wiederholt ihn in einem stabilen Workflow. Vergleicht Vollständigkeit, Rework und Review-Aufwand über einen definierten Zeitraum, bevor ihr Richtlinie oder Tooling ausweitet. Ein einzelner Bericht beweist keinen ROI.