Ein reproduzierbarer Fehler ist gemeldet, aber es fehlt ein Test, der ihn dauerhaft festhält. Ohne einen solchen Test kann derselbe Fehler unbemerkt wiederkehren, sobald sich der betroffene Code erneut ändert.
Abgrenzung — nicht automatisiert: Nicht automatisiert: die Einstufung des Fehlers als reproduzierbar und relevant bleibt eine menschliche Entscheidung, ebenso die Freigabe des Fixes und der Gegenprüfung vor dem Merge.
Voraussetzungen
Eine im Tracker beschriebene, reproduzierbare Fehlermeldung.
Ein Stack-Profil mit den vorhandenen Test-Kommandos des Projekts.
Guardrails, die eine Testpflicht für Fehlerkorrekturen festhalten.
Freigabe, dass die Korrektur inklusive Regressionstest ausgeführt werden darf.
Ablauf
Die Fehlermeldung aus dem Tracker wird in einen Plan mit Reproduktionsschritt überführt.
Ein Regressionstest wird ergänzt, der den Fehler vor der Korrektur nachweisbar rot zeigt.
Die eigentliche Korrektur wird umgesetzt, bis derselbe Test grün ist.
Die Gegenprüfung läuft gegen die vollständige betroffene Testsuite, nicht nur den neuen Test.
Ergebnis geht als Pull Request an das Repository, mit Verweis auf die Fehlermeldung.
Ergebnisartefakte
Der neue Regressionstest bleibt Teil der Testsuite und schützt vor Wiederkehr.
Vorher-/Nachher-Status des Tests im Commit-Verlauf nachvollziehbar.
Ein Pull Request mit Verweis auf die ursprüngliche Fehlermeldung.
Vermerk, ob verwandte Stellen im Code auf denselben Fehler geprüft wurden.
Alle Beispiele auf dieser Seite sind zur Veranschaulichung erstellt. Sie sind keine Zusage über Dauer, Qualität oder Kosten eines künftigen eigenen Laufs — die eigenen Zahlen zeigt das Cockpit nach der Anmeldung, im eigenen Tenant-Kontext.
