·
8 min
Root-Cause-Analyse in der Softwareentwicklung: Fehlerursachen von fehlgeschlagenen Tests finden
Roman Kirchmeier - Autemos
Die Root-Cause-Analyse in der Softwareentwicklung ermittelt den Zustand, der Softwarefehler und fehlgeschlagene Tests erst möglich gemacht hat. Der deutsche ISTQB-Lehrplan nennt das Verfahren Grundursachenanalyse; das ISTQB-Glossar definiert es als „The process used to identify the root cause of a defect“ (ISTQB-Glossar, Stand 2026). In QA-Teams beginnt sie meist mit einem roten Testlauf und einer Frage: Liegt der Fehler im Produkt, im Test, in der Umgebung oder in den Testdaten? Bei Google betrafen rund 84 % der beobachteten Wechsel von bestanden zu fehlgeschlagen einen Flaky Test (Google Testing Blog, 2016). Die Analyse ist ein Teilschritt im Fehlermanagement im Softwaretest.
Kurz gefasst: Eine Root-Cause-Analyse trennt Symptom, Auslöser und Grundursache. Bei einem fehlgeschlagenen Test sichern Sie zuerst die Belege, reproduzieren den Lauf und ordnen ihn einer von fünf Kategorien zu: Produktfehler, Testfehler, Umgebung, Testdaten oder Flaky Test. Erst danach helfen 5 Whys und Ishikawa.
Abbildung 1: Fünf Kategorien für einen roten Testlauf
Was ist eine Root-Cause-Analyse nach ISTQB?
Eine Root-Cause-Analyse ist ein Analyseverfahren, das den grundlegenden Grund eines Fehlerzustands ermittelt. Der deutsche ISTQB-Lehrplan formuliert: „Eine Grundursache (root cause) ist ein wesentlicher Grund für das Auftreten eines Problems (z. B. eine Situation, die zu einer Fehlhandlung führt).“ (GTB, CTFL-Lehrplan 4.0.2, 2025)
Der Lehrplan beschreibt dazu eine Kette: Menschen begehen Fehlhandlungen, diese erzeugen Fehlerzustände, und Fehlerzustände können zu Fehlerwirkungen führen. Fehlerwirkungen entstehen laut Syllabus zusätzlich durch Umgebungsbedingungen (ISTQB CTFL Syllabus 4.0.1, 2024). Eine rote Testausführung kann darum einen Fehlerzustand im Produkt anzeigen oder eine gestörte Umgebung.
Laut Lehrplan findet die Analyse statt, wenn eine Fehlerwirkung auftritt oder ein Fehlerzustand festgestellt wird. Das ISTQB erwartet, dass sich ähnliche Fehlerwirkungen oder Fehlerzustände verhindern oder seltener machen lassen, wenn die Grundursache angegangen wird. Welche Status ein Fehler bis zur Schließung durchläuft, zeigt der Beitrag zum Fehlerlebenszyklus.
Worin unterscheiden sich Auslöser und Grundursache?
Der Auslöser (Trigger) ist das Ereignis, das ein Problem sichtbar macht; die Grundursache ist der Zustand, der es ermöglicht hat. Das Google SRE Workbook schreibt: „Identifying the root causes and trigger is one of the most important reasons to write a postmortem.“ (Google SRE Workbook, 2018)
Abbildung 2: Auslöser und Grundursache im Vergleich
Ein Muster-Postmortem im Workbook beschreibt einen seit Langem vorhandenen Fehler in der Eingabeprüfung des Traffic-Admin-Servers. Ausgelöst wurde er durch eine manuelle Wiederholung („was triggered by the manual reexecution“). Der alte Fehler ist die Grundursache, die manuelle Wiederholung der Auslöser.
Im Test ist ein Deployment, ein Datenbank-Update oder ein neuer Browser-Build der typische Auslöser. Google SRE beobachtet intern, dass rund 70 % der Ausfälle auf Änderungen in einem Live-System zurückgehen (Google SRE Book, 2016). Das ist eine Google-Zahl ohne veröffentlichte Methodik, keine Branchenstatistik.
Wie läuft eine Root-Cause-Analyse für einen fehlgeschlagenen Test ab?
Eine Root-Cause-Analyse für einen fehlgeschlagenen automatisierten Test oder einen Produktionsfehler folgt in der Praxis acht Schritten, von der Beweissicherung bis zum Regressionstest. Der CTFL-Lehrplan schreibt kein festes Verfahren vor; die folgende Reihenfolge stammt aus der Testautomatisierung:
Problem eingrenzen. Welcher Test, seit wann, in welcher Umgebung, auf welchem Build? Notieren Sie die Auswirkung.
Belege sichern, bevor jemand neu startet. Testreport, Logs, Screenshots, Aufzeichnung, Telemetrie. Ein schneller Rerun überschreibt oft den einzigen Hinweis.
Reproduzieren. Gleicher Build, gleiche Testdaten, gleiche Umgebung. Tritt die Fehlerwirkung immer, gelegentlich oder gar nicht wieder auf?
Erstklassifizieren. Ordnen Sie den Fall einer der fünf Kategorien aus der folgenden Tabelle zu.
Auslöser und Grundursache trennen. Welche Änderung hat den Fehler sichtbar gemacht, welcher Zustand hat ihn ermöglicht?
Ursachenkette aufbauen. 5 Whys für eine lineare Kette, Ishikawa für mehrere Ursachen.
Maßnahmen festlegen. Je eine Korrektur- und Vorbeugemaßnahme, mit verantwortlicher Person und Termin.
Absichern. Fehlernachtest für die Behebung, Regressionstest für das Umfeld. Der behobene Fehler wird zum automatisierten Test.
Welche Felder ein brauchbarer Bericht braucht, steht in unserer Vorlage für einen Fehlerbericht.
Wie ordnen Sie einen fehlgeschlagenen automatisierten Test ein?
Ein fehlgeschlagener automatisierter Test fällt in eine von fünf Kategorien: Produktfehler, Testfehler, Umgebung, Testdaten oder Flaky Test. Diese Einteilung ist Praxis aus Testteams, keine Norm. Der Lehrplan stützt sie: Gemeldete Anomalien können sich als „falsch positives Ergebnis“ herausstellen (GTB, CTFL-Lehrplan 4.0.2, 2025).
Abbildung 3: Flaky Tests bei Google (Google Testing Blog, 2016)
Kategorie | Typisches Anzeichen | Erster Prüfschritt | Nächster Schritt |
|---|---|---|---|
Produktfehler | Fachliches Ergebnis weicht ab, reproduzierbar | Im selben Build manuell nachstellen | Fehlerbericht an die Entwicklung |
Testfehler | Locator oder Assertion passt nicht zur gewollten Änderung | Änderung an Oberfläche oder Testskript vergleichen | Test anpassen, kein Produktticket |
Umgebung | Timeout, Zertifikatsfehler, Dienst nicht erreichbar | Test in einer zweiten Umgebung starten | Ticket an Betrieb oder Infrastruktur |
Testdaten | Datensatz fehlt, gesperrt oder verbraucht | Datenzustand vor dem Lauf prüfen | Daten bereinigen, Datenregeln prüfen |
Flaky Test | Gleicher Code, mal grün, mal rot | Mehrfach wiederholen, Verlauf ansehen | Ursache beheben oder Test isolieren |
Bei Google meldeten etwa 1,5 % aller Testläufe ein „flaky“-Ergebnis, und fast 16 % der Tests zeigten ein gewisses Maß an Flakiness (Google Testing Blog, 2016). Ein Rerun bis zum grünen Ergebnis verschiebt die Analyse.
Ein Flaky Test hat selbst eine Grundursache. Laut Luo et al. (2014) gehören asynchrones Warten, Nebenläufigkeit und Abhängigkeiten von der Testreihenfolge zu den häufigsten Ursachen (Luo et al., FSE, 2014). Wie instabile Locators Flakiness erzeugen, erklärt der Beitrag zu Self-Healing Locators.
Wie wenden Sie 5 Whys und Ishikawa auf einen roten Test an?
Die 5 Whys liefern eine lineare Ursachenkette für einen einzelnen Fehler, das Ishikawa-Diagramm sammelt mehrere mögliche Ursachen nach Kategorien. Das Lean Enterprise Institute beschreibt 5 Whys als „the practice of asking why repeatedly whenever a problem is encountered“ (Lean Enterprise Institute, Stand 2026). Die Methode geht auf das Toyota-Produktionssystem zurück und wurde von Taiichi Ohno bekannt gemacht (Card, BMJ Qual Saf, 2017).
Abbildung 4: Ishikawa-Diagramm, angepasst an Softwarefehler
Beispiel: 5 Whys für einen fehlgeschlagenen Überweisungstest
Das Beispiel ist zur Illustration konstruiert. Ein nächtlicher Test „Überweisung freigeben“ schlägt im Bestätigungsschritt fehl.
Warum schlägt der Test fehl? Die Bestätigungsseite zeigt eine Fehlermeldung statt der Freigabe.
Warum die Fehlermeldung? Der Zahlungsdienst lehnt ab, das Testkonto ist gesperrt.
Warum ist das Konto gesperrt? Ein paralleler Lauf hat denselben Datensatz kurz vorher für einen Sperrtest genutzt.
Warum war das möglich? Der Datensatz war nicht als einmalig verwendbar markiert.
Warum fehlte die Markierung? Neue Testfälle durchlaufen kein Review ihrer Testdaten.
Kategorie: Testdaten, die Grundursache steckt im Prozess; im Produkt liegt kein Fehlerzustand vor. Korrektur: Konto entsperren. Vorbeugung: Einmal-Daten kennzeichnen und Testdaten neuer Testfälle reviewen.
Wie sieht ein Ishikawa-Diagramm für Software aus?
Das Ishikawa-Diagramm (Fischgrätendiagramm) geht auf Kaoru Ishikawa zurück und zählt laut ASQ zu den sieben grundlegenden Qualitätswerkzeugen (ASQ, Stand 2026). Die klassischen 6 M stammen aus der Fertigung: Material, Maschine, Methode, Messung, Mensch, Mitwelt. Für Softwarefehler nutzen wir diese Anpassung:
Produktcode und Konfiguration
Testcode (Locator, Assertion, Wartelogik)
Testdaten
Testumgebung und Infrastruktur
Abhängigkeiten (Drittsysteme, APIs, Browser-Versionen)
Prozess (Review, Deployment, Übergaben), anstelle von „Mensch“, passend zum Blameless-Ansatz weiter unten
Wo liegen die Grenzen der 5 Whys?
Für die Wirksamkeit der 5 Whys gibt es kaum Belege. Alan J. Card kritisiert in BMJ Quality & Safety, die Methode erzwinge eine einzige lineare Kette, die Zahl fünf sei willkürlich und das Ergebnis hänge von der untersuchenden Person ab (Card, BMJ Qual Saf, 2017). Ihre Verbreitung führt er auf „pedigree, simplicity and pedagogy“ zurück.
Das Beispiel hatte zwei Ursachen, die fehlende Markierung und das fehlende Review; ein Ishikawa-Diagramm zeigt beide.
Was gehört in ein Blameless Postmortem?
Ein Postmortem ist laut Google SRE ein schriftlicher Bericht über einen Vorfall, seine Auswirkung, die ergriffenen Maßnahmen, die Grundursache(n) und die Folgemaßnahmen gegen eine Wiederholung (Google SRE Book, 2016). Blameless heißt laut Google SRE: Das Postmortem benennt die beitragenden Ursachen, ohne Einzelne oder Teams zu beschuldigen („focus on identifying the contributing causes of the incident without indicting any individual or team“).
Ein roter Nachtlauf braucht eine Kurzfassung im Ticket, ein Produktionsfehler mit Kundenwirkung die volle Fassung. In beiden Fällen gehören zwei Arten von Maßnahmen getrennt hinein:
Korrekturmaßnahme: behebt den konkreten Fall, etwa per Code-Fix, bereinigtem Datensatz oder angepasstem Locator.
Vorbeugemaßnahme: verhindert, dass dieselbe Grundursache wieder Fehler erzeugt, etwa per Eingabeprüfung, Review-Schritt, neuem Regressionstest oder Monitoring.
Viele Vorbeugemaßnahmen setzen früher im Prozess an, das Thema von Shift-Left-Testing.
Was verlangt DORA bei der Ursachenanalyse?
DORA verlangt von EU-Finanzunternehmen, bei IKT-bezogenen Vorfällen die Ursachen zu ermitteln, zu dokumentieren und anzugehen. Art. 17 Abs. 2 der Verordnung (EU) 2022/2554 fordert Verfahren, „um sicherzustellen, dass Ursachen ermittelt, dokumentiert und angegangen werden“ (EUR-Lex, DORA, 2022). Die Verordnung gilt seit dem 17. Januar 2025.
Für schwerwiegende Vorfälle sieht Art. 19 Abs. 4 Buchst. c „eine Abschlussmeldung, wenn die Ursachenanalyse abgeschlossen ist“ vor. DORA regelt Vorfälle im Betrieb, keine Fehlerverwaltung im Test. Ein Softwarefehler wird relevant, sobald er einen IKT-bezogenen Vorfall verursacht. Schweizer Banken richten sich nach FINMA RS 2023/1 zu operationellen Risiken inklusive IKT-Risiken; DORA betrifft sie nur über EU-Geschäft. Der Beitrag zum Audit Trail im Testing zeigt, wie diese Nachweise prüfbar bleiben.
Was liefert Autemos für die Root-Cause-Analyse?
Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Die Software liefert die Belege für die Root-Cause-Analyse; die Analyse selbst führt Ihr Team durch. Autemos ist kein Defect-Tracker. Es ersetzt weder Jira noch Azure DevOps und legt weder Fehlerschweregrad noch Priorität fest.
Self-Healing getrennt dokumentiert: Jede Self-Healing-Aktion steht im Report und lässt sich prüfen, ablehnen oder zurücknehmen. Ein geänderter Locator erscheint als testseitige Änderung, nicht als Produktfehler.
Reproduzierbarkeit: Der visuelle Test-Workflow ist die Schrittfolge, und exportierter Playwright- oder Appium-Code läuft außerhalb von Autemos erneut.
Belege: Ergebnisse landen in Autemos-Reports und Allure; Logs und Telemetrie können an Splunk oder Dynatrace gehen.
Umgebung und Daten: Die Konfiguration pro Umgebung hält fest, wo ein Test lief. Einmal-Testdaten werden markiert, damit parallele Läufe sie nicht doppelt nutzen.
Regressionstest aus dem Ticket: Der KI-Chat entwirft aus einem Jira-Ticket einen Test-Workflow. Jeder KI-generierte Schritt braucht vor der Ausführung die Freigabe des Teams.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Root-Cause-Analyse und Fehlerbehebung?
Die Fehlerbehebung entfernt einen konkreten Fehlerzustand, die Root-Cause-Analyse klärt, warum er entstanden ist, damit das Team die Ursache angehen kann.
Ist jeder fehlgeschlagene Test ein Softwarefehler?
Nein, ein roter Test kann ebenso auf Testcode, Umgebung, Testdaten oder Flakiness zurückgehen. Der ISTQB-Lehrplan nennt falsch positive Ergebnisse ausdrücklich.
Wie viele Warum-Fragen braucht die 5-Why-Methode?
So viele, bis Sie eine Ursache erreichen, die Ihr Team angehen kann. Die Zahl fünf ist laut Alan J. Card (BMJ Quality & Safety, 2017) willkürlich. Hat ein Fehler mehrere Ursachen, passt ein Ishikawa-Diagramm besser.
Wer sollte eine Root-Cause-Analyse durchführen?
Entwicklung und QA gemeinsam, bei Produktionsfehlern zusammen mit dem Betrieb. Google SRE verlangt, dass das Postmortem beitragende Ursachen benennt, ohne Personen oder Teams zu beschuldigen.
Müssen Banken nach DORA Grundursachen dokumentieren?
Bei IKT-bezogenen Vorfällen in EU-Finanzunternehmen ja: Art. 17 Abs. 2 DORA verlangt, dass Ursachen ermittelt, dokumentiert und angegangen werden. Fehler, die nur im Test auftreten, fallen nicht darunter.
Fazit
Eine Root-Cause-Analyse beginnt bei fehlgeschlagenen Tests mit gesicherten Belegen und einer ehrlichen Erstklassifizierung: Produkt, Test, Umgebung, Testdaten oder Flakiness. Erst danach lohnen sich 5 Whys oder ein Ishikawa-Diagramm. Trennen Sie Auslöser und Grundursache, halten Sie Korrektur- und Vorbeugemaßnahmen getrennt fest und sichern Sie die Behebung mit Fehlernachtest und Regressionstest ab.
Für EU-Finanzunternehmen kommt bei IKT-bezogenen Vorfällen die Pflicht aus DORA Art. 17 hinzu, Ursachen zu dokumentieren. Die Denkarbeit bleibt beim Team. Ein Werkzeug kann die Belege vollständig halten und verhindern, dass eine Self-Healing-Reparatur als Produktfehler in die Analyse gerät.
Sie möchten sehen, wie Autemos Testläufe, Self-Healing-Aktionen und Reports für Ihre Root-Cause-Analyse bereitstellt? Vereinbaren Sie ein Gespräch mit unserem Team.
