Einen Fehler beheben, indem man ihn zuerst mit einem fehlschlagenden Test nachstellt

## Vor dem Ändern des Codes einordnen, welcher Teil des Systems für den Fehler zuständig ist Beginne mit der beobachtbaren Auswirkung, nicht mit der Datei, in der das Symptom aufgetreten ist. Eine brauchbare Ersteingrenzung zeigt der nächsten untersuchenden Person, was fehlgeschlagen ist, wer oder was betroffen ist und welche Komponente das Verhalten verantwortet. ### Vor dem Handeln einordnen - Ordne den Fehler dem Kernverhalten, dem System- oder Integrationsverhalten oder der Laufzeitumgebung des Hostsystems zu. - Unterscheide die Komponente, die das Symptom anzeigt, von der Komponente, die das fehlerhafte Verhalten steuert. - Leite die Arbeit an die verantwortliche Systemgrenze weiter, wenn die Belege außerhalb der aktuellen Komponente liegen. ### Beweisrahmen festlegen Halte die auslösende Eingabe, den Anfangszustand, die genauen Nutzerhandlungen, das erwartete Ergebnis, das tatsächliche Ergebnis und die maßgebliche Umgebung fest. Führe Tatsachen getrennt von Hypothesen auf. Ändere während der Ersteingrenzung keinen Implementierungsquelltext; in der nächsten Stufe muss zunächst ein reproduzierbares Fehlverhalten nachgewiesen werden. Die Einordnung ist vorläufig. Wenn spätere Belege ihr widersprechen, kehre hierher zurück, passe die Abgrenzung an und verschiebe den Test in die Schicht, die das Verhalten tatsächlich verantwortet. ## Das für Nutzer sichtbare Fehlverhalten mit einem fehlschlagenden Test nachstellen Überführe den Bericht in das kürzeste wiederholbare Szenario, das weiterhin dem Nutzererlebnis entspricht. Behalte die wesentliche Eingabe, den Zustand, die Abfolge und das sichtbare Ergebnis bei; entferne nebensächliche Vorbereitungsschritte, die den Fehler nicht beeinflussen. ### Wähle die nächstgelegene zuverlässige Testschicht - Verwende für isolierte Logik einen gezielten Einheiten- oder Komponententest. - Verwende einen Integrations- oder Systemtest, wenn Speicherung, Darstellung, Übertragung oder mehrere Komponenten beteiligt sind. - Verwende einen Browsertest oder durchgängigen Systemtest, wenn der Fehler von realer Interaktion, Fokus, zeitlichem Ablauf, Navigation oder sichtbarem Zustand abhängt. Schreibe den Regressionstest, bevor du den Quelltext änderst. Führe ihn aus und bestätige, dass er aus dem gemeldeten Grund fehlschlägt, nicht wegen einer fehlerhaften Einrichtung, veralteter Ressourcen, fehlender Daten oder einer unzutreffenden Prüfung. Ein Test, dessen Fehlschlag nie beobachtet wurde, ist kein Beleg für den Fehler. Wenn sich das Verhalten nicht automatisieren lässt, dokumentiere den Grund und erfasse die stärkste wiederholbare Alternative, etwa ein deterministisches manuelles Verfahren, eine Folge von Bildschirmaufnahmen, eine Ablaufspur oder ein gemessenes Ergebnis. Lasse den Implementierungsquelltext unverändert, bis der Fehlernachweis verlässlich ist. ## Die erste Stelle finden, an der das Verhalten abweicht, und die Grundursache eingrenzen Beginne die Untersuchung erst, wenn die fehlschlagende Reproduktion stabil ist. Formuliere mehrere plausible Hypothesen und prüfe sie mit gezielten Beobachtungen, anstatt mehrere Dinge gleichzeitig zu ändern. ### Verfolge die erste Abweichung Verfolge die fehlschlagende Eingabe durch Zustandsänderungen, Systemgrenzen und den Steuerfluss. Vergleiche einen erfolgreichen Fall mit dem fehlschlagenden Fall und finde die früheste Stelle, an der das tatsächliche vom erwarteten Verhalten abweicht. Prüfe erzeugte Artefakte, gespeicherte Werte, Antworten angebundener Systeme oder den zeitlichen Ablauf nur dort, wo sie laut Reproduktion maßgeblich sind. Sage für jede Hypothese voraus, welche Belege sie bestätigen oder widerlegen würden, führe die kleinste unterscheidende Prüfung aus und halte das Ergebnis fest. Unterscheide die Grundursache von Folgeschäden und von Bedingungen, die den Fehler lediglich leichter sichtbar machen. Ändere während der Ursachenabgrenzung keine Produktivlogik. Wenn alle Hypothesen scheitern, kehre zur Reproduktion zurück, prüfe ihre Annahmen, verfeinere die Einordnung und formuliere eine neue, durch Belege gestützte Hypothese. ## Mit der kleinsten Änderung beheben und den Test gegen Regressionen behalten Sobald die Grundursache eingegrenzt ist, ändere nur die kleinste Fläche, die das beabsichtigte Verhalten wiederherstellt. Bewahre öffentliche Schnittstellen und unbeteiligtes Verhalten und vermeide Bereinigung, Neugestaltung oder Umstrukturierung, die für den fehlschlagenden Fall nicht erforderlich ist. Führe zuerst den ursprünglich fehlschlagenden Test aus. Er muss nun bestehen, weil die Ursache beseitigt wurde, nicht weil die Prüfung abgeschwächt, das Szenario übersprungen oder der Testaufbau so verändert wurde, dass er den Fehler nicht mehr auslöst. Behalte den Test als dauerhaften Regressionsschutz bei. Führe danach die direkt betroffene Testgruppe sowie die maßgeblichen statischen Prüfungen, Quelltextprüfungen oder Typprüfungen aus. Erweitere den Umfang nur dann auf eine größere Testsammlung, wenn die Änderung gemeinsame Systemgrenzen überschreitet oder die engeren Belege auf ein breiteres Risiko hinweisen. Behandle jeden neuen Fehlschlag als Beleg: Behebe entweder eine echte Regression oder kehre zur Ursachenabgrenzung zurück, wenn die vorgeschlagene Korrektur unvollständig war. Prüfe den abschließenden Änderungssatz auf unbeabsichtigte Änderungen, doppelte Logik, abgeschwächte Prüfungen und fehlende Randfälle. Die Korrektur ist in dieser Stufe nur abgeschlossen, wenn das gezielte Verhalten und seine direkt betroffenen Nachbarbereiche alle Prüfungen bestehen. ## Die Schritte der Nutzer in einer echten Umgebung wiederholen, bevor der Fehler als behoben gilt Automatisierte Tests sind notwendig, ersetzen aber nicht die Bestätigung des tatsächlichen Nutzerwegs. Wiederhole das ursprüngliche, für Nutzer sichtbare Verfahren in einer repräsentativen Laufzeitumgebung mit derselben wesentlichen Eingabe und demselben Zustand, die den Fehler offengelegt haben. Vergleiche das sichtbare Ergebnis vor und nach der Änderung. Bestätige gegebenenfalls außerdem das gespeicherte Ergebnis, die dargestellte Ausgabe, das ausgelöste Ereignis, die Übergabe an ein angebundenes System oder das neu erstellte Artefakt, von dem die Nutzer letztlich abhängen. Halte Umgebung, Schritte und beobachtetes Ergebnis fest, damit eine andere Person die Schlussfolgerung prüfen kann. Wenn das manuelle Verhalten weiterhin fehlschlägt, vom automatisierten Ergebnis abweicht oder eine undokumentierte Umgehung erfordert, erkläre den Fehler nicht für behoben. Kehre zur Einordnung oder Reproduktion zurück, erweitere den Test um die übersehene Bedingung und wiederhole den Kreislauf aus Ursache, Korrektur, Regressionsschutz und Prüfung. Schließe mit einem knappen Belegbericht ab: Fehlerklasse, bestätigte Reproduktion, Grundursache, kleinste Änderung, Regressionsabdeckung, direkt betroffene Prüfungen und Ergebnis des tatsächlichen Ablaufs. Füge nur dann eine wiederverwendbare Vorbeugungsregel hinzu, wenn der Fehler eine wiederkehrende Architekturfamilie erkennen lässt; einmalige Einzelheiten verbleiben im Test und in der Änderungshistorie.