Der Fehlerlebenszyklus ist die Folge von Status, die ein gemeldeter Fehler zwischen Meldung und Schließung durchläuft: offen, in Arbeit, behoben, nachgetestet, geschlossen oder wiedereröffnet. Der deutsche ISTQB-Lehrplan CTFL 4.0.2 nennt acht Beispiele für den Fehlerstatus, von „offen“ bis „zurückgewiesen“ (GTB, Lehrplan CTFL 4.0.2, 2025). Jira, Azure DevOps und Bugzilla bilden denselben Ablauf mit eigenen Namen ab. Der Status ist ein Feld im Fehlerbericht und zeigt, wer als Nächstes handeln muss. Ein behobener Fehler wird erst geschlossen, wenn der Fehlernachtest bestanden ist; eine spätere Regression bekommt einen eigenen Bericht.

Kurz gefasst: Der Fehlerlebenszyklus führt einen Fehlerbericht von „offen“ über „auf Behebung wartend“ und „auf Fehlernachtest wartend“ bis „geschlossen“, mit Seitenausgängen für doppelte, zurückgestellte und zurückgewiesene Meldungen. Ein behobener Fehler wird erst nach bestandenem Fehlernachtest geschlossen. Tritt der Fehler später als Regression wieder auf, empfiehlt Microsoft einen neuen, verknüpften Bug statt einer Wiedereröffnung.

Abbildung 1: Der Fehlerlebenszyklus mit den Status aus dem ISTQB-Lehrplan

Was ist der Fehlerlebenszyklus?

Der Fehlerlebenszyklus (englisch „bug life cycle“ oder „defect life cycle“) ist ein festgelegter Arbeitsablauf, der jeden gemeldeten Fehlerzustand über definierte Status bis zur Schließung führt. Laut Lehrplan umfasst der Prozess des Fehlermanagements mindestens „einen Arbeitsablauf für die Behandlung einzelner Fehlerzustände oder Anomalien von ihrer Entdeckung bis zu ihrer Schließung“ (GTB, 2025).

Der Fehlerstatus ist ein Feld im Fehlerbericht. Er zeigt auf einen Blick, wo eine Meldung steht und wer als Nächstes handeln muss. Der Lebenszyklus selbst ist ein Teilprozess im Fehlermanagement im Softwaretest, das zusätzlich Klassifizierung, Analyse und Kennzahlen umfasst.

Nicht jede Meldung ist ein echter Fehler. Laut Lehrplan können sich gemeldete Anomalien als Fehlerzustand oder „als etwas anderes herausstellen (z. B. falsch positives Ergebnis, Änderungsanforderung)“ (GTB, 2025). Genau dafür gibt es Status wie „zurückgewiesen“. Ein Beispiel zur Illustration: Ein Tester meldet eine falsche Zinsanzeige, die Fachabteilung stuft sie als gewünschtes Verhalten ein, der Bericht endet als „zurückgewiesen“.

Welche Fehlerstatus nennt der ISTQB-Lehrplan?

Der deutsche ISTQB-Lehrplan nennt acht Beispiele für den Fehlerstatus: offen, zurückgestellt, doppelt, auf Behebung wartend, auf Fehlernachtest wartend, wiedereröffnet, geschlossen und zurückgewiesen (GTB, 2025). Die Liste steht hinter einem „z. B.“; sie zeigt Beispiele und schreibt keinen Workflow vor.

So lassen sich die acht Status lesen:

• offen: gemeldet, aber noch nicht bewertet oder zugewiesen.

• auf Behebung wartend: als Fehlerzustand bestätigt, die Entwicklung ist am Zug.

• auf Fehlernachtest wartend: die Entwicklung meldet eine Behebung, der Nachtest steht aus.

• geschlossen: Nachtest bestanden, der Fehlerbericht ist abgeschlossen.

• wiedereröffnet: der Nachtest ist gescheitert, die Fehlerwirkung tritt weiter auf.

• zurückgestellt: ein echter Fehler, dessen Behebung das Team bewusst verschiebt.

• doppelt: derselbe Fehlerzustand ist schon gemeldet.

• zurückgewiesen: kein Fehlerzustand, etwa ein falsch positives Ergebnis.

Drei dieser Status beenden den Zyklus ohne Behebung: doppelt, zurückgewiesen und oft zurückgestellt. Jira und Azure DevOps führen sie als Abschlussgrund (Resolution) neben dem Status „geschlossen“. Wer ISTQB-Begriffe und Tool-Begriffe mischt, sollte diesen Punkt im Team einmal klären.

Wie läuft der Fehlerlebenszyklus typischerweise ab?

Ein typischer Fehlerlebenszyklus hat sechs Schritte: melden, bewerten, beheben, als behoben markieren, nachtesten und schließen oder wiedereröffnen. Jeder Schritt hat einen klaren Besitzer. Der englische ISTQB-Lehrplan (CTFL 4.0.1) nennt die Kernaktivitäten: Anomalien protokollieren, analysieren und klassifizieren, über die Reaktion entscheiden und den Bericht schließen (ISTQB CTFL 4.0.1, 2024).

1. Melden (Tester, Fachbereich oder Nutzer): Der Fehlerbericht entsteht. Kennung, Datum, Autor und Anfangsstatus kann das Tool laut ISTQB automatisch setzen. Status: offen.

2. Bewerten (Triage): Das Team prüft, ob ein Fehlerzustand vorliegt, setzt Fehlerschweregrad und Priorität und entscheidet: beheben, zurückstellen, als doppelt oder zurückgewiesen schließen. Laut Microsoft leitet typischerweise der Project Owner die Triage-Meetings (Microsoft Learn, 2026).

3. Beheben (Entwicklung): Eine Entwicklerin übernimmt den Fehler. Status: auf Behebung wartend, dann in Arbeit.

4. Als behoben markieren (Entwicklung): Die Korrektur ist ausgeliefert. Status: auf Fehlernachtest wartend (in Jira sowie Azure DevOps Agile und CMMI „Resolved“).

5. Nachtesten (Testteam oder Ersteller): In den Azure-DevOps-Prozessen Agile und CMMI prüft die Person, die den Bug erstellt hat, die Behebung und schließt ihn (Microsoft Learn, 2026).

6. Schließen oder wiedereröffnen (Testteam): Bestanden heißt geschlossen. Gescheitert heißt wiedereröffnet, und der Fehler geht zurück an Schritt 3.

Der Lehrplan hält fest: „Der Prozess muss von allen Beteiligten befolgt werden.“ (GTB, 2025). In der Praxis heißt das: Legen Sie im Tool fest, welche Rolle welchen Übergang auslösen darf. Wir empfehlen die Regel, dass niemand den eigenen Fix selbst schließt.

Wie heißen die Fehlerstatus in Jira, Azure DevOps und Bugzilla?

Jira, Azure DevOps und Bugzilla bilden denselben Fehlerlebenszyklus mit eigenen Statusnamen ab und trennen den Status (wo steht der Fehler?) vom Abschlussgrund (warum wurde er geschlossen?). Bugzilla beschreibt den Zweck so: Status und Resolution decken alles ab, „from not even being confirmed as a bug, through to being fixed and the fix confirmed by Quality Assurance“ (Bugzilla-Dokumentation).

Abbildung 2: Dieselben Phasen, unterschiedliche Statusnamen in Jira, Azure DevOps und Bugzilla

In der Azure-DevOps-Spalte stehen links vom Punkt die Prozesse Agile und CMMI (bei unterschiedlichen Namen als Agile / CMMI), rechts davon der Prozess Scrum. Der Azure-DevOps-Prozess Basic hat gar keinen Bug-Typ.

Quellen: Atlassian, Microsoft Learn (2026), Bugzilla. Die Bugzilla-Namen entsprechen dem Standard-Workflow ab Version 4.0; die offizielle Dokumentation zeigt ihn nur als Diagramm, und jede Installation kann ihn ändern. Auch Jira und Azure DevOps lassen sich anpassen. Jira-Status hängen von der Vorlage ab, vereinfachte Vorlagen arbeiten mit To Do und Done.

Die Abschlussgründe unterscheiden sich stärker als die Status:

Ein Detail mit Folgen: „zurückgestellt“ ist im ISTQB-Beispiel ein Status, in Azure DevOps Agile und CMMI dagegen der Abschlussgrund „Deferred“ eines geschlossenen Bugs. Ein zurückgestellter Fehler verschwindet dort aus jeder Abfrage auf offene Bugs. Klären Sie, ob verschobene Fehler bei Ihnen offen bleiben sollen.

Fehlernachtest oder Regressionstest: Was folgt nach der Behebung?

Nach einer Behebung folgen zwei verschiedene Tests: Der Fehlernachtest prüft den behobenen Fehler selbst, der Regressionstest prüft die Auswirkungen der Änderung auf den Rest des Systems. Der Lehrplan definiert: „Fehlernachtest bestätigt, dass ein ursprünglicher Fehlerzustand erfolgreich behoben wurde.“ Und: „Der Regressionstest bestätigt, dass eine Änderung, einschließlich einer bereits getesteten Fehlerbehebung, keine nachteiligen Folgen hat.“ (GTB, 2025). Der Fehlernachtest entscheidet über „geschlossen“ oder „wiedereröffnet“, der Regressionstest prüft die übrigen Funktionen.

Abbildung 3: Fehlernachtest und Regressionstest prüfen nach der Behebung Verschiedenes

Für den Nachtest nennt der englische ISTQB-Lehrplan (CTFL 4.0.1) zwei Wege: alle Tests erneut ausführen, die wegen des Fehlers gescheitert sind, oder neue Tests für die geänderten Stellen ergänzen. Bei Zeitdruck reicht es, die Schritte zu wiederholen, die die Fehlerwirkung reproduzieren, und zu prüfen, dass sie nicht mehr auftritt (ISTQB CTFL 4.0.1, 2024).

Microsoft gibt eine klare Regel für Fehler, die nach dem Schließen zurückkehren: „Don’t reopen closed bugs for regressions. Instead, open a new bug and link it to the original with a Related link.“ (Microsoft Learn, 2026). Wiedereröffnen passt zum gescheiterten Nachtest. Eine spätere Regression ist ein neuer Fehler mit eigener Ursache und verdient einen eigenen Bericht.

Wie oft werden Fehler wiedereröffnet?

In den hier zitierten Open-Source-Studien wurden rund 6 bis 10 Prozent der Bugs wiedereröffnet (vier Eclipse-Projekte, Mi und Keung 2016) und rund 6 Prozent über 589 Jira-Projekte (Tagra et al. 2022); eine allgemeingültige Branchenquote gibt es nicht. Die Werte hängen stark vom Datensatz ab. Lesen Sie sie als Orientierung für Ihre eigene Messung.

Abbildung 4: Wiedereröffnungsraten aus zwei Open-Source-Studien

Nicht reproduzierbare Meldungen sind ein eigener Engpass. Laut Joorabchi, Mirzaaghaei und Mesbah betreffen sie 17 Prozent aller untersuchten Fehlerberichte und bleiben rund drei Monate länger aktiv (MSR 2014). Mozilla nennt die Reproduktionsschritte „the most important part of any bug report“ (Mozilla Bug Writing Guidelines, 2026). Gute Schritte im Fehlerbericht senken das Risiko, dass eine Meldung als nicht reproduzierbar endet.

Eine hohe Wiedereröffnungsrate in Ihrem Projekt kann auf schwache Nachtests oder unklare Abnahmekriterien hindeuten; prüfen Sie die betroffenen Berichte einzeln. Messen Sie die Rate getrennt von neuen Regressionen, sonst vermischt die Kennzahl zwei Probleme. Wie solche Werte in Testberichte gehören, erklärt unser Beitrag zum Testreporting.

Wann ist ein Fehler erledigt?

Ein Fehler ist erledigt, wenn der Fehlernachtest bestanden ist, der Regressionstest grün läuft und der Bericht mit Status und Abschlussgrund geschlossen wurde. Diese Kriterien gehören in die Definition of Done Ihres Teams, damit niemand „behoben“ und „erledigt“ verwechselt.

Eine praxistaugliche Checkliste:

• Die Korrektur ist im Zielbuild, und die Version steht im Fehlerbericht.

• Der Fehlernachtest ist in der richtigen Testumgebung bestanden.

• Ein Regressionstest deckt die Fehlerwirkung künftig ab.

• Status „geschlossen“ und ein passender Abschlussgrund sind gesetzt.

• Der Bericht verweist auf Testfall, Testlauf und Code-Änderung.

Wo hilft Autemos im Fehlerlebenszyklus und wo nicht?

Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Im Fehlerlebenszyklus unterstützt Autemos vor allem den Fehlernachtest und den Regressionstest. Autemos ist kein Defect-Tracker. Jira, Azure DevOps oder Bugzilla bleiben das System, in dem Fehlerstatus gesetzt werden.

Wo Autemos hilft:

• Fehlernachtest per Wiederholung: Hat ein automatisierter Autemos-Test den Fehler gefunden, ist sein visueller Test-Workflow genau die Schrittfolge, die gescheitert ist. Sie führen ihn nach dem Fix erneut aus. Der exportierte Playwright- oder Appium-Code läuft auch außerhalb von Autemos.

• Aus dem Fix wird ein Regressionstest: Der AI Recorder entwirft per KI-Chat aus dem Jira-Ticket einen ausführbaren Test-Workflow. Jeder KI-generierte Schritt muss vom Team freigegeben werden, bevor er läuft.

• Jira/Xray-Sync: Testfälle und Testausführungen synchronisieren bidirektional mit Jira/Xray, das Nachtest-Ergebnis ist dort sichtbar.

• Selbstheilung mit Protokoll: Jede Locator-Heilung steht im Report und lässt sich zurückrollen. Ein geänderter Locator erscheint so als Änderung am Test und wird nicht mit einem Produktfehler verwechselt.

Wo Autemos nicht hilft: Es legt keine Bug-Tickets automatisch an, setzt keinen Fehlerstatus, bestimmt weder Fehlerschweregrad noch Priorität und ersetzt keine Grundursachenanalyse. Die Entscheidung über „geschlossen“ oder „wiedereröffnet“ trifft ein Mensch. Status, Fehlerschweregrad und Abschlussgrund pflegen Sie weiter in Jira, Azure DevOps oder Bugzilla.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Fehlerstatus und Abschlussgrund?

Der Fehlerstatus zeigt, wo ein Fehler im Ablauf steht, der Abschlussgrund erklärt, warum er geschlossen wurde. Bugzilla trennt Status wie RESOLVED von Resolutions wie FIXED oder DUPLICATE, Jira kennt etwa die Resolutions Done, Won’t do, Duplicate und Cannot reproduce (Atlassian).

Wer darf einen Fehler schließen?

Meist schließt die Person, die den Fehler gemeldet hat, oder das Testteam nach bestandenem Fehlernachtest. In Azure DevOps Agile und CMMI prüft laut Microsoft der Ersteller die Behebung und schließt den Bug (Microsoft Learn, 2026). Wer den Fix gebaut hat, sollte ihn nicht selbst schließen.

Wann wird ein Fehler wiedereröffnet und wann neu gemeldet?

Wiedereröffnet wird ein Fehler, wenn der Fehlernachtest scheitert. Taucht dieselbe Fehlerwirkung nach dem Schließen als Regression wieder auf, empfiehlt Microsoft einen neuen Bug mit „Related“-Verknüpfung zum Original (Microsoft Learn, 2026). So bleiben Historie und Wiedereröffnungsrate aussagekräftig.

Was bedeutet der Fehlerstatus „zurückgestellt“?

„Zurückgestellt“ bedeutet, dass das Team einen bestätigten Fehler bewusst später behebt, etwa in einem kommenden Release. Der ISTQB-Lehrplan führt ihn als Beispiel für einen Fehlerstatus. In Azure DevOps Agile und CMMI ist „Deferred“ dagegen ein Abschlussgrund, der Bug gilt dort als geschlossen.

Gibt es einen Standard-Fehlerlebenszyklus?

Einen verbindlichen Standard gibt es nicht: Der ISTQB-Lehrplan nennt seine acht Fehlerstatus ausdrücklich als Beispiele („z. B.“). Jira, Azure DevOps und Bugzilla liefern eigene Standard-Workflows, die sich anpassen lassen. In Bugzilla legen Administratoren die erlaubten Übergänge in einem Raster fest (Bugzilla).

Fazit

Der Fehlerlebenszyklus macht sichtbar, wo jeder gemeldete Fehler steht und wer als Nächstes handelt. Die acht ISTQB-Beispiele von „offen“ bis „zurückgewiesen“ decken die gängigen Fälle ab; Jira, Azure DevOps und Bugzilla benennen sie anders und verschieben manche Fälle vom Status in den Abschlussgrund. Drei Regeln gelten: Ein behobener Fehler wird erst nach bestandenem Fehlernachtest geschlossen. Wiedereröffnet wird nur, wenn dieser Nachtest scheitert. Eine spätere Regression bekommt einen neuen, verknüpften Bug. Wer zusätzlich jeden behobenen Fehler in einen Regressionstest überführt, sieht eine Rückkehr desselben Fehlers in der Regel schon im nächsten Testlauf. Wenn Sie prüfen möchten, wie Autemos Fehlernachtests und Regressionstests aus Jira-Tickets in Ihrem Team abbilden kann, sprechen Sie mit uns.