Fehlermanagement im Softwaretest ist der Prozess, mit dem ein Team gemeldete Anomalien protokolliert, analysiert, klassifiziert, über ihre Behebung entscheidet und den Fehlerbericht schließt. So beschreibt es Abschnitt 5.5 des ISTQB-Lehrplans Foundation Level (ISTQB CTFL Lehrplan 4.0.2, 2025). Das offizielle Glossar nennt sechs Tätigkeiten: „recognizing, recording, classifying, investigating, fixing and disposing of defects“ (ISTQB Glossary, 2026).

In der Praxis heißt das: Bei jedem Fehler ist klar, wer ihn meldet, wer entscheidet, wer behebt und wer den Fehlernachtest macht. Fehlermanagement ist ein Teilprozess des Testmanagements. Für Banken und Versicherer in der EU kommt eine zweite Ebene dazu: IKT-bezogene Vorfälle im Betrieb fallen unter die DORA-Verordnung, das Bug-Tracking im Test regelt sie nicht.

Kurz gefasst: Fehlermanagement hat vier Kernaktivitäten: Anomalie protokollieren, analysieren und klassifizieren, über die Reaktion entscheiden, Fehlerbericht schließen. Jede Meldung kann sich als echter Fehlerzustand, falsch positives Ergebnis oder Änderungsanforderung herausstellen. Die Fehlerfindungsrate (DDP) misst den Anteil, den eine Teststufe findet. Eine Studie mit 171 TSP-Projekten fand keinen Beleg dafür, dass spät behobene Fehler grundsätzlich teurer sind (Menzies et al., 2016).

Abbildung 1: Die vier Kernaktivitäten des Fehlermanagements nach ISTQB

Was ist Fehlermanagement im Softwaretest?

Fehlermanagement im Softwaretest ist ein Prozess, der jede gemeldete Anomalie über einen festen Workflow von der Meldung bis zur Schließung führt und nach vereinbarten Regeln klassifiziert. Laut ISTQB umfasst er „mindestens einen Arbeitsablauf für die Behandlung einzelner Fehlerzustände oder Anomalien“ und Regeln für ihre Klassifizierung (ISTQB CTFL Lehrplan 4.0.2, 2025).

Die Begriffe bilden eine Kette. Ein Mensch begeht eine Fehlhandlung (error), die einen Fehlerzustand (defect, Bug) im Code oder in einem Dokument erzeugt. Wird der Fehlerzustand ausgeführt, kann eine Fehlerwirkung (failure) auftreten, das heißt ein beobachtbares Fehlverhalten. Laut Lehrplan können Fehlerwirkungen zusätzlich durch Umgebungsbedingungen entstehen (ISTQB CTFL v4.0.1, 2024).

Der Begriff Fehlermanagement bezeichnet in vielen Unternehmen die Fehlerkultur im Umgang mit menschlichen Fehlern; hier geht es um Fehlerzustände in Software. Der Lehrplan empfiehlt, Befunde aus statischen Tests, besonders aus der statischen Analyse, auf ähnliche Weise zu behandeln wie Befunde aus der Testdurchführung.

Ist jede Meldung ein echter Fehler?

Eine Meldung ist zunächst eine Anomalie, deren Natur erst die Analyse klärt. Der Lehrplan sagt ausdrücklich, dass sich gemeldete Anomalien „als tatsächliche Fehlerzustände oder als etwas anderes herausstellen“ können, etwa als falsch positives Ergebnis oder als Änderungsanforderung (GTB, 2025).

Diese Trennung hat praktische Folgen. Wer jede Meldung sofort als Bug zählt, bläht die Fehlerstatistik auf und schickt Entwickler auf die Suche nach Fehlern, die es im Produkt nicht gibt. Ein sauberes Fehlermanagement führt darum eigene Endzustände für Duplikate, zurückgewiesene Meldungen und Änderungsanforderungen.

Wie läuft der Fehlermanagement-Prozess nach ISTQB ab?

Der ISTQB-Workflow hat vier Kernaktivitäten: gemeldete Anomalien protokollieren, sie analysieren und klassifizieren, über eine Reaktion entscheiden (Behebung oder Beibehaltung) und den Fehlerbericht schließen (ISTQB CTFL Lehrplan 4.0.2, 2025). Zwischen Entscheidung und Schließung liegen in der Praxis die Behebung, der Fehlernachtest und der Regressionstest.

Abbildung 2: Workflow vom Protokollieren bis zum Schließen, mit typischen Rollen

1. Protokollieren: Die meldende Person erfasst die Anomalie als Fehlerbericht mit Status „offen“. Werkzeuge vergeben Kennung, Datum, Autor und Anfangsstatus oft automatisch.

2. Analysieren und klassifizieren: Ist die Wirkung reproduzierbar? Gibt es den Bericht schon? Handelt es sich um einen Fehlerzustand im Produkt, ein falsch positives Ergebnis oder eine Änderungsanforderung? Hier wird der Fehlerschweregrad gesetzt.

3. Reaktion entscheiden: beheben, zurückstellen, zurückweisen oder als Änderungsanforderung weitergeben. Dazu gehört die Priorität für die Behebung.

4. Beheben: Die Entwicklung ändert Code oder Konfiguration und verweist im Bericht auf die Änderung.

5. Fehlernachtest: „Fehlernachtest bestätigt, dass ein ursprünglicher Fehlerzustand erfolgreich behoben wurde.“ (GTB, 2025)

6. Regressionstest: Er prüft, ob die Änderung, einschließlich der Fehlerbehebung, an anderer Stelle nachteilige Folgen hat.

7. Schließen: Der Bericht erhält den Status „geschlossen“ und bleibt als Nachweis erhalten.

Die Schritte 1 bis 3 und 7 stammen aus Abschnitt 5.5 des Lehrplans, die Schritte 5 und 6 aus Abschnitt 2.2.3; Schritt 4 ist die Praxis dazwischen. Der Lehrplan ergänzt: „Der Prozess muss von allen Beteiligten befolgt werden.“ (ISTQB CTFL Lehrplan 4.0.2, 2025) Ein Entwickler, der Fehler per Chat meldet, umgeht ihn.

Wer übernimmt welche Rolle im Fehlermanagement?

Vier Rollen tragen den Prozess: Wer meldet, wer sichtet und priorisiert (Triage), wer behebt und wer den Fehlernachtest bestätigt. Triage ist ein Praxisbegriff aus Werkzeugen wie Bugzilla und Azure DevOps. Bei Microsoft heißt es: „Typically, the project owner runs the bug triage meetings.“ (Microsoft Learn, 2026)

• Meldende Person: Tester, Entwickler, Fachbereich oder Betrieb. Bei Mozilla setzt das QA-Team für Bugs, die es meldet oder reproduziert, einen ersten Fehlerschweregrad (Mozilla Triage Policy, 2026).

• Triage-Runde: Product Owner, Testmanager und Entwicklung prüfen neue Berichte, markieren Duplikate und vergeben die Priorität. Mozilla verlangt für jede Änderung des Fehlerschweregrads einen begründenden Kommentar.

Die folgende Tabelle ordnet jedem Schritt ein Artefakt und eine typische Rolle zu. Die Rollenzuordnung ist ein verbreitetes Muster, keine ISTQB-Vorgabe.

Was gehört in einen Fehlerbericht?

Ein Fehlerbericht (Bug Report) ist ein Dokument, das Auftreten, Art und Status eines Fehlerzustands festhält, so die Definition des „defect report“ im ISTQB-Glossar (ISTQB Glossary, 2026). Der Lehrplan nennt drei Ziele: genug Information für die Behebung, die Verfolgung der Qualität des Arbeitsergebnisses und Ideen zur Verbesserung des Entwicklungs- und Testprozesses.

Der Lehrplan nennt 11 Inhalte, von der eindeutigen Kennung über Testumgebung und Testschritte bis zu erwartetem und tatsächlichem Ergebnis, Fehlerschweregrad, Priorität, Fehlerstatus und Referenzen (GTB, 2025). Vorlagen enthält die Norm ISO/IEC/IEEE 29119-3, die von „Abweichungsberichten“ spricht.

Das wichtigste Feld sind die Reproduktionsschritte. Die Bugzilla-Richtlinie von Mozilla schreibt: „Steps to reproduce are the most important part of any bug report.“ (Mozilla Bug Writing Guidelines, 2026) Dieselbe Richtlinie empfiehlt eine Zusammenfassung unter 60 Zeichen, die das Problem beschreibt und keinen Lösungsvorschlag enthält.

Die Forschung stützt das. Eine Umfrage unter Entwicklern und Nutzern von Apache, Eclipse und Mozilla ergab bei 466 Antworten eine Lücke zwischen dem, was Entwickler brauchen, und dem, was Meldende liefern. Reproduktionsschritte, Stacktraces und Testfälle halfen den Entwicklern am meisten und waren für Nutzer am schwersten zu liefern (Zimmermann et al., IEEE TSE, 2010).

Eine vollständige Vorlage mit Feldliste und einem ausgefüllten Bankbeispiel finden Sie im Beitrag Fehlerbericht schreiben: Vorlage und Beispiel.

Wie hängen Fehlerstatus, Fehlerschweregrad und Priorität zusammen?

Der Fehlerstatus zeigt, wo ein Bericht im Workflow steht, der Fehlerschweregrad beschreibt den Grad der Auswirkung, und die Priorität legt fest, wie dringend behoben wird. Der Lehrplan nennt als Statusbeispiele offen, zurückgestellt, doppelt, auf Behebung wartend, auf Fehlernachtest wartend, wiedereröffnet, geschlossen und zurückgewiesen (GTB, 2025).

Welche Zustände ein Team nutzt und wie Jira, Azure DevOps oder Bugzilla sie benennen, erklärt der Beitrag zum Fehlerlebenszyklus und seinen Statuswerten. Microsoft rät: „Don’t reopen closed bugs for regressions.“ Stattdessen legt man einen neuen Bug an und verknüpft ihn mit dem alten (Microsoft Learn, 2026).

Wiedereröffnungen kommen regelmäßig vor. In vier Eclipse-Projekten führten 6 bis 10 % aller Bugs irgendwann zu einer Wiedereröffnung (Mi & Keung, EASE, 2016). Wer den Status „wiedereröffnet“ konsequent nutzt, kann diesen Anteil im eigenen Projekt messen.

Was unterscheidet Fehlerschweregrad und Priorität?

Der Fehlerschweregrad misst die Auswirkung, die Priorität die Dringlichkeit. Das offizielle Glossar definiert Severity als „The degree of impact that a defect has on the development, testing or operation of a component or system.“ (ISTQB Glossary, 2026) Priority lautet dort generisch „The level of importance assigned to a task according to specific criteria.“ (ISTQB Glossary, 2026) Die ältere Fassung mit „business importance“ kursiert noch in Mirror-Seiten.

Beide Werte können auseinanderfallen. Microsoft nennt als Beispiel einen selten genutzten Link, der die Anwendung abstürzen lässt: Severity 2 (High), Priority 3 (Microsoft Learn, 2026). Skalen von Mozilla, Azure DevOps, Jira und CVSS vergleicht der Beitrag zu Schweregrad und Priorität von Fehlern.

Wie findet ein Team die Grundursache eines Fehlers?

Die Grundursachenanalyse (Root-Cause-Analyse, RCA) ist der Prozess, mit dem ein Team die Grundursache eines Fehlerzustands ermittelt; das ISTQB-Glossar nennt ihn „The process used to identify the root cause of a defect.“ (ISTQB Glossary, 2026) Laut Lehrplan findet sie normalerweise statt, wenn eine Fehlerwirkung auftritt oder ein Fehlerzustand festgestellt wird.

Der Lehrplan formuliert den Nutzen vorsichtig: Es wird angenommen, dass sich ähnliche Fehlerwirkungen verhindern oder seltener machen lassen, wenn man die Grundursache angeht (ISTQB CTFL v4.0.1, 2024). Ein Beispiel: Ein Test schlägt fehl, ausgelöst durch einen Rundungsfehler. Die Grundursache liegt vielleicht in einer unklaren Anforderung zur Rundungsregel.

Googles Regel für schuldfreie Postmortems lässt sich übertragen: die beitragenden Ursachen finden, „without indicting any individual or team for bad or inappropriate behavior“ (Google SRE Book, 2016).

Methoden wie 5 Whys und Ishikawa, angewandt auf fehlgeschlagene Tests, beschreibt der Beitrag zur Root-Cause-Analyse bei Softwarefehlern.

Welche Kennzahlen zeigen, ob das Fehlermanagement funktioniert?

Der ISTQB-Lehrplan nennt als Fehlerkennzahlen die Anzahl und Prioritäten gefundener und behobener Fehler, die Fehlerdichte und die Fehlerfindungsrate (Defect Detection Percentage, DDP) (ISTQB CTFL v4.0.1, 2024). Dazu kommt der Begriff Escaped Defect für Fehler, die eine Testaktivität hätte finden sollen. Wie man sie berichtet, zeigt der Beitrag zum Testreporting.

Abbildung 3: Median-Fixzeiten aus 171 TSP-Projekten (Menzies et al. 2016)

Wie berechnet man die Fehlerfindungsrate (DDP)?

Das Glossar definiert DDP als „The number of defects found by a test level, divided by the number found by that test level and any other means afterwards.“ (ISTQB Glossary, 2026) Als Formel: DDP = Fehler der Teststufe ÷ (Fehler der Teststufe + später gefundene Fehler) × 100.

Rechenbeispiel (Illustration, keine Messdaten): Der Systemtest findet 90 Fehlerzustände, die Produktion bringt danach weitere 10 hervor. DDP = 90 ÷ (90 + 10) × 100 = 90 %. Die Zahl ist erst nach einer Beobachtungsphase stabil: Spät gefundene Fehler verändern sie rückwirkend.

Was ist ein Escaped Defect, und was misst die Fehlerdichte?

Ein Escaped Defect ist laut Glossar „A defect that is not detected by a test activity that is supposed to find it.“ (ISTQB Glossary, 2026) Der verbreitete Begriff „Defect Leakage“ ist Praxissprache und kein Eintrag im ISTQB-Glossar.

Die Fehlerdichte ist die Anzahl der Fehlerzustände pro Größeneinheit eines Arbeitsergebnisses (ISTQB-Glossar v3.4 via imbus, 2020). In der Praxis zählt man meist pro 1.000 Codezeilen (KLOC) oder pro Function Point. Vergleiche über Teams hinweg ergeben nur Sinn, wenn Einheit und Zählregel gleich sind.

Stimmt die 1:10:100-Regel?

Die 1:10:100-Regel, nach der ein Fehler pro Phase zehnmal teurer wird, ist eine historische Faustregel und kein belegtes Gesetz. Sie geht auf Boehm (1981) zurück, der für größere Projekte einen hundertfachen Anstieg berichtete. Menzies und Kollegen prüften die These an 171 Projekten aus den Jahren 2006 bis 2014 mit 47.376 Fehlerprotokollen (Menzies et al., arXiv/EMSE, 2016).

Ihr Ergebnis: „We found no evidence for the delayed issue effect.“ Codierfehler brauchten im Median etwa 10 Minuten im Code-Review und 13 Minuten im Systemtest, Anforderungsfehler etwa 13 Minuten im Review und 33 Minuten im Integrationstest. Die Daten stammen aus dem Team Software Process (TSP), einer disziplinierten Methode, die einer der Autoren mitentwickelt hat.

Daraus folgt nicht, dass späte Fehler nie teurer sind. Die Autoren halten den Effekt für ein mögliches Relikt, das nur in bestimmten Projekten auftritt. Wer frühes Testen begründen will, argumentiert besser mit eigenen Fixzeiten aus dem Defect-Tracker als mit dem Faktor 100.

Was gilt für Fehlermanagement in regulierten Finanzunternehmen?

DORA, die Verordnung (EU) 2022/2554, regelt das Management IKT-bezogener Vorfälle bei EU-Finanzunternehmen und gilt seit dem 17. Januar 2025; Bug-Tracking im Test regelt sie nicht. Ein Softwarefehler wird DORA-relevant, sobald er einen IKT-bezogenen Vorfall verursacht. Artikel 17 Absatz 2 beginnt mit dem Satz: „Finanzunternehmen erfassen alle IKT-bezogenen Vorfälle und erheblichen Cyberbedrohungen.“ (EUR-Lex, DORA, 2022)

Abbildung 4: Fehlermanagement im Test und IKT-Incident-Management nach DORA im Vergleich

Derselbe Artikel verlangt, Ursachen zu ermitteln, zu dokumentieren und anzugehen. Absatz 3 Buchstabe b fordert Verfahren, die Vorfälle nach Priorität und Schwere und nach der Kritikalität der betroffenen Dienste klassifizieren. Für schwerwiegende IKT-bezogene Vorfälle sieht Artikel 19 Absatz 4 Buchstabe c eine Abschlussmeldung vor, „wenn die Ursachenanalyse abgeschlossen ist“ (EUR-Lex, DORA, 2022).

Für Schweizer Banken gilt das FINMA-Rundschreiben 2023/1, das das Management operationeller Risiken einschließlich IKT-Risiken bei Banken regelt. DORA trifft Schweizer Institute nur über EU-Geschäft oder EU-Tochtergesellschaften. Weitere Pflichten für Testprozesse in Banken beschreibt der Beitrag zur Testautomatisierung in regulierten Banken.

Wenn ein Vorfall in Produktion auf einen Fehlerzustand zurückgeht, verweist das Incident-Ticket auf den Fehlerbericht, und der Fehlernachtest belegt die Behebung. Google beobachtete intern, dass rund 70 % der Ausfälle auf Änderungen an einem laufenden System zurückgehen (Google SRE Book, 2016). Regressionstests nach jeder Änderung setzen genau dort an.

Wie fließen automatisierte Testläufe ins Fehlermanagement ein?

Ein fehlgeschlagener automatisierter Test ist eine Anomalie, noch kein bestätigter Fehlerzustand im Produkt: Die Ursache kann im Produkt, im Testskript, in der Umgebung, in den Testdaten oder in Flakiness liegen. Google meldete, dass rund 1,5 % aller Testläufe ein flaky Ergebnis lieferten und etwa 16 % der Tests eine gewisse Flakiness zeigten (Google Testing Blog, 2016).

Laut demselben Beitrag betrafen etwa 84 % der beobachteten Wechsel von „bestanden“ zu „fehlgeschlagen“ einen flaky Test. Wer jeden roten Testlauf ungeprüft als Bug meldet, füllt den Defect-Tracker mit Fehlalarmen. Vor dem Fehlerbericht steht darum eine Einordnung in fünf Klassen:

• Produktfehler: Die Anwendung verhält sich falsch. Dieser Fall gehört in den Fehlerbericht.

• Testfehler: Skript, Locator oder erwartetes Ergebnis ist falsch.

• Umgebung: Dienst nicht erreichbar, falsche Konfiguration, abgelaufenes Zertifikat.

• Testdaten: Datensatz verbraucht, verändert oder fehlend.

• Flaky: Der Test liefert bei unverändertem Code unterschiedliche Ergebnisse.

Was trägt Autemos bei, und was nicht?

Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Autemos ist kein Defect-Tracker. Es ersetzt weder Jira noch Azure DevOps noch Bugzilla, legt keine Bug-Tickets automatisch an, setzt weder Fehlerschweregrad noch Priorität und übernimmt keine Grundursachenanalyse. Entwickelt wird Autemos von der selementrix GmbH in Baar (Zug).

Für den Fehlerbericht liefert Autemos Belege aus dem Testlauf:

• Der visuelle Testworkflow ist die Schrittfolge, die zum Fehler führte. Exportierter Playwright- oder Appium-Code läuft außerhalb von Autemos erneut.

• Ergebnisse landen in Autemos-Berichten und Allure-Reports; Logs und Telemetrie können nach Splunk oder Dynatrace gehen.

• Testausführungen synchronisieren sich in beide Richtungen mit Jira/Xray, siehe die Jira/Xray-Integration. Die Mechanik erklärt der Beitrag zu Xray in Jira.

• Jede Self-Healing-Aktion steht im Bericht und lässt sich prüfen, ablehnen oder zurücknehmen. Ein geänderter Locator erscheint so als Änderung am Test und nicht als Produktfehler.

• Die Konfiguration pro Umgebung (DEV, TEST, STAGING, PROD) hilft festzuhalten, in welcher Umgebung der Fehler auftrat. Der Audit-Trail dokumentiert, wer was geändert hat; Rollenrechte legen fest, wer ändern darf.

• Aus einem behobenen Fehler kann ein Regressionstest werden: Der KI-Chat entwirft einen Testworkflow aus dem Jira-Ticket, und das Team gibt jeden KI-generierten Schritt frei, bevor er läuft.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Fehlermanagement und Incident-Management?

Fehlermanagement behandelt Anomalien und Fehlerzustände in Testobjekten, Incident-Management behandelt Störungen im laufenden Betrieb. Bei einem EU-Finanzunternehmen wird ein Softwarefehler DORA-relevant, sobald er im Betrieb einen IKT-bezogenen Vorfall auslöst.

Wer darf einen Fehlerbericht schließen?

Üblicherweise schließt das Testteam den Bericht nach einem bestandenen Fehlernachtest; Duplikate und zurückgewiesene Meldungen schließt die Triage-Runde. Das ISTQB schreibt keine Rolle vor, verlangt aber, dass alle Beteiligten demselben Prozess folgen. Legen Sie die Regel im Workflow Ihres Werkzeugs fest, damit sie für jeden Bericht gilt.

Was ist der Unterschied zwischen Fehlernachtest und Regressionstest?

Der Fehlernachtest prüft, ob ein bestimmter Fehlerzustand behoben ist; der Regressionstest prüft, ob die Änderung anderswo Schaden angerichtet hat. Laut Lehrplan bestätigt der Regressionstest, „dass eine Änderung, einschließlich einer bereits getesteten Fehlerbehebung, keine nachteiligen Folgen hat“ (GTB, 2025). Beide gehören vor das Schließen des Berichts.

Schreibt DORA ein Bug-Tracking-Werkzeug vor?

Nein, DORA schreibt weder ein Bug-Tracking-Werkzeug noch ein Format für Fehlerberichte vor. Die Verordnung verlangt, IKT-bezogene Vorfälle zu erfassen, nach Priorität und Schwere zu klassifizieren und Ursachen zu ermitteln, zu dokumentieren und anzugehen. Geht ein Vorfall auf einen Softwarefehler zurück, belegen der verknüpfte Fehlerbericht und der Fehlernachtest Ursache und Behebung.

Ersetzt Autemos einen Defect-Tracker wie Jira?

Nein, Autemos ersetzt keinen Defect-Tracker. Es automatisiert funktionale Tests und liefert reproduzierbare Testläufe, Allure-Reports und eine bidirektionale Synchronisation von Testausführungen mit Jira/Xray. Fehlerberichte, Fehlerschweregrad, Priorität und Status verwalten Sie weiter in Jira, Azure DevOps oder Bugzilla.

Fazit

Fehlermanagement im Softwaretest besteht aus vier Aktivitäten aus dem ISTQB-Lehrplan: protokollieren, analysieren und klassifizieren, entscheiden, schließen. Klare Rollen, ein Fehlerbericht mit reproduzierbaren Schritten und getrennte Werte für Fehlerschweregrad und Priorität halten den Prozess sauber.

Messen Sie den Prozess mit DDP, Escaped Defects und Fehlerdichte, und begründen Sie frühes Testen mit Fixzeiten aus Ihrem eigenen Defect-Tracker. In regulierten Finanzunternehmen trennen Sie Fehlerberichte aus dem Test sauber von IKT-Vorfällen nach DORA, verknüpfen beide aber dort, wo ein Fehler einen IKT-bezogenen Vorfall verursacht hat.

Ordnen Sie jeden roten Testlauf ein, bevor er zum Bug wird. Wenn Sie sehen wollen, wie reproduzierbare Testläufe und die Jira/Xray-Synchronisation in Ihr Fehlermanagement passen, sprechen Sie mit uns.