Schweregrad und Priorität von Fehlern beantworten zwei getrennte Fragen: wie stark ein Fehlerzustand ein System beeinträchtigt und wie dringend das Team ihn behebt. Der offizielle ISTQB-Begriff für die erste Angabe lautet „Fehlerschweregrad“, im Teamalltag hat sich die Kurzform durchgesetzt. Beide Werte können weit auseinanderliegen. Für einen seltenen Absturz schlägt Microsoft „Severity = 2 - High“ und nur Priorität 3 vor (Microsoft Learn, 2026). Mozilla, Azure DevOps und Jira verwenden dafür jeweils eigene Skalen. Wie die Einstufung in den gesamten Ablauf passt, zeigt der Leitfaden zum Fehlermanagement im Softwaretest.

Kurz gefasst: Der Schweregrad (ISTQB: Fehlerschweregrad) beschreibt die Auswirkung eines Fehlers, die Priorität die Reihenfolge der Behebung. Beide Werte gehören in den Fehlerbericht, die Priorität setzt die Triage nach festgelegten Kriterien wie Release-Termin und Risiko. Für einen seltenen Absturz über einen Remote-Link schlägt Microsoft Severity 2 - High mit Priority 3 vor: schwer, aber nicht dringend.

Abbildung 1: Schweregrad beschreibt die Auswirkung, Priorität die Reihenfolge der Behebung

Was ist der Unterschied zwischen Schweregrad und Priorität?

Der Fehlerschweregrad ist ein Attribut eines Fehlerberichts, das die Auswirkung eines Fehlers beschreibt; die Priorität legt die Wichtigkeit des Fehlers und damit die Reihenfolge der Behebung fest. Das offizielle ISTQB-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). Gemeint ist die Wirkung auf Entwicklung, Test oder Betrieb.

Für die Priorität steht im Glossar heute eine offen gehaltene Formulierung: „The level of importance assigned to a task according to specific criteria“ (ISTQB Glossary, 2026). Die inoffizielle Spiegelseite istqb-glossary.page und KI-Antworten wie die von ChatGPT zitieren noch eine ältere Fassung, die von „(business) importance“ spricht und einen Fehlerzustand als Beispiel nennt. Die aktuelle Definition spricht von Aufgaben und von festgelegten Kriterien.

Daraus folgt eine praktische Pflicht: Wer Prioritäten vergibt, muss die Kriterien aufschreiben. Typische Kriterien sind Release-Termin, Zahl der betroffenen Nutzer, Kundenzusagen und regulatorische Fristen. Fehlt diese Liste, wird die Priorität im Meeting verhandelt, und es gewinnt die lauteste Stimme.

Im deutschen Lehrplan CTFL 4.0.2 stehen beide Angaben nebeneinander im Fehlerbericht: der „Fehlerschweregrad (Grad der Auswirkung) der Fehlerwirkung auf die Interessen der Stakeholder oder Anforderungen“ und die „Priorität für die Behebung“ (GTB, 2025). Die erste Angabe beschreibt den Fehler, die zweite eine Entscheidung über Arbeit.

Schweregrad vs. Priorität im direkten Vergleich

Die beiden Felder trennen sich in vier Punkten: wer sie festlegt, welche Frage sie beantworten, wann sie sich ändern und welche Skalen üblich sind. Die Tabelle fasst das zusammen, mit Belegen aus den Dokumentationen von Mozilla und Microsoft.

Die 7 Severity-Stufen von Eclipse ließen sich kaum auseinanderhalten. Herraiz, German, González-Barahona und Robles gruppierten die Fehler nach Bearbeitungszeit und fanden weniger klar trennbare Gruppen als Stufen; sie schlugen ein einfacheres Formular vor (Herraiz et al., MSR, 2008).

Für die eigene Skala spricht das für wenige, klar beschriebene Stufen. Mozilla und Azure DevOps kommen mit je 4 aus. Jede Stufe braucht ein Beispiel aus dem eigenen Produkt.

Wie sieht die 2×2-Matrix aus Schweregrad und Priorität aus?

Die 2×2-Matrix kombiniert hohen und niedrigen Schweregrad mit hoher und niedriger Priorität und ergibt vier Fälle mit je eigener Behandlung in der Triage. Belegt ist der Fall „hoch, aber nicht dringend“ durch Microsoft mit einem seltenen Remote-Link, der eine Anwendung abstürzen lässt (Microsoft Learn, 2026).

Abbildung 2: Die 2×2-Matrix aus Schweregrad und Priorität (Bankbeispiele zur Illustration)

Die Bankbeispiele in der Tabelle sind Illustrationen, keine dokumentierten Fälle. Sie zeigen, wie die Logik in einem Finanzinstitut aussehen kann.

Die Matrix selbst ist eine Branchenkonvention und keine Norm. Ihr Nutzen liegt in der Diskussion: Wenn ein Team einen Fehler nicht eindeutig einem Quadranten zuordnen kann, fehlen meist Fakten zur Auswirkung oder die Prioritätskriterien sind nicht aufgeschrieben.

Welche Skalen nutzen Mozilla, Azure DevOps, Jira und CVSS?

Mozilla und Azure DevOps arbeiten mit je 4 Schweregradstufen, bei der Priorität reichen die dokumentierten Skalen von 3 Stufen (Azure DevOps) bis 5 Stufen (Mozilla, Jira). Gleiche Zahlen bedeuten dabei nicht dasselbe: Ein „P3“ bei Mozilla heißt Backlog, eine „Priority 3“ bei Azure DevOps heißt optionale Behebung.

Abbildung 3: Schweregrad-Skalen bei Mozilla, Azure DevOps und CVSS 4.0

Mozilla (Bugzilla)

Mozilla beschreibt seine aktuellen Stufen im Feldhandbuch (Mozilla Wiki, 2026):

• S1 (Catastrophic): blockiert Entwicklung oder Test, kann mehr als 25 % der Nutzer betreffen, Datenverlust, kein Workaround

• S2 (Serious): wichtige Funktionalität stark beeinträchtigt, kein zufriedenstellender Workaround

• S3 (Normal): blockiert unkritische Funktionalität oder es gibt einen Workaround

• S4 (Small/Trivial): geringe Bedeutung, kosmetische Fehler, kaum Auswirkung auf Nutzer

Bei der Priorität steht P1 für das laufende Release, P2 für das nächste oder übernächste, P3 für den Backlog. P5 bedeutet „Will not fix, but will accept a patch“.

Azure DevOps

Microsoft dokumentiert für Bugs 4 Schweregrade: 1 - Critical (muss behoben werden, kein akzeptabler Ausweg), 2 - High (gleiche Wirkung, es gibt einen akzeptablen Ausweg), 3 - Medium (Standard; falsche, unvollständige oder inkonsistente Ergebnisse) und 4 - Low (kleiner oder kosmetischer Fehler). Für die Priorität sind 3 Stufen beschrieben: 1 muss vor der Auslieferung gelöst und bald angegangen werden, 2 muss vor der Auslieferung gelöst werden, 3 ist optional (Microsoft Learn, 2026).

Jira

Jira bringt standardmäßig 5 Prioritäten mit: Highest, High, Medium, Low und Lowest. Administratoren können sie pro Projekt anpassen (Atlassian Support, 2026). Wie Teams einen Schweregrad in Jira abbilden, hängt von ihrer Konfiguration ab.

CVSS

CVSS bewertet den Schweregrad einer Sicherheitslücke, nicht die Dringlichkeit ihrer Behebung. Version 4.0 erschien am 1. November 2023 und vergibt Werte von 0.0 bis 10.0, mit der optionalen Einteilung None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9) und Critical (9.0–10.0) (FIRST, 2024). Wann ein Team eine Lücke mit Score 7.5 schließt, hängt vom Kontext ab, etwa davon, ob das System aus dem Internet erreichbar ist.

Wer entscheidet in der Bug-Triage über Schweregrad und Priorität?

In der Bug-Triage legt eine feste Runde die Priorität fest und bestätigt oder korrigiert den Schweregrad. Microsoft schreibt: „Typically, the project owner runs the bug triage meetings“ (Microsoft Learn, 2026). Teamleitungen, Business-Analysten und weitere Stakeholder nehmen teil.

Abbildung 4: Eine Triage-Runde in 5 Schritten

Mozilla regelt die Rollen genauer. Triager dürfen den Wert der meldenden Person übersteuern, QA setzt für eigene Bugs einen Anfangswert. Die Regel dazu lautet: „Changing a bug’s severity requires a comment explaining the rationale“ (Mozilla Firefox Source Docs, 2026). Die Priorität ist für Triager optional.

Eine Triage-Runde lässt sich in 5 Schritten organisieren:

1. Neue Meldungen sichten und aussortieren, was kein Fehlerzustand ist. Der ISTQB-Lehrplan nennt falsch positive Ergebnisse und Änderungsanforderungen als mögliche Ergebnisse (GTB, 2025).

2. Reproduzierbarkeit prüfen und fehlende Angaben anfordern. Was ein vollständiger Fehlerbericht enthält, ist dort beschrieben.

3. Den Schweregrad bestätigen oder ändern und jede Änderung schriftlich begründen.

4. Die Priorität anhand der aufgeschriebenen Kriterien setzen: Release-Termin, betroffene Kunden, Risiko, regulatorische Fristen.

5. Zuständigkeit und Zielrelease festlegen und für schwere Fälle eine Root-Cause-Analyse anstoßen.

Felder werden häufig nachträglich geändert. Xia, Lo, Wen, Shihab und Zhou werteten 190 558 Fehlerberichte aus 4 Open-Source-Projekten aus: Bei rund 80 % wurde mindestens ein Feld neu zugewiesen, und diese Fehler brauchten länger bis zur Behebung (Xia et al. 2014, zusammengefasst in Xia et al. 2016). Die Zahl gilt für alle Felder zusammen, nicht für den Schweregrad allein.

Was verlangt DORA bei Priorität und Schwere von Vorfällen?

DORA verpflichtet Finanzunternehmen in der EU, IKT-bezogene Vorfälle nach Priorität und Schwere zu klassifizieren. Art. 17 Abs. 3 lit. b der Verordnung (EU) 2022/2554 fordert Verfahren zur Klassifizierung „entsprechend ihrer Priorität und Schwere und entsprechend der Kritikalität der betroffenen Dienste“ (EUR-Lex, 2022). Die Verordnung gilt seit dem 17. Januar 2025.

Die Vorschrift betrifft Vorfälle im Betrieb, keine Fehlerberichte aus dem Test. Ein Softwarefehler wird relevant, sobald er einen IKT-bezogenen Vorfall auslöst. Dann verlangt Art. 17 Abs. 2, dass Ursachen „ermittelt, dokumentiert und angegangen werden“. Einen Bugtracker oder ein Format für Fehlerberichte schreibt DORA nicht vor.

Schweizer Banken betrifft DORA nur über EU-Geschäft oder EU-Tochtergesellschaften. Für sie regelt das FINMA-Rundschreiben 2023/1 das Management operationeller Risiken inklusive IKT-Risiken. Wer im Test schon zwei getrennte Felder pflegt, kann dieselbe Logik im Incident-Prozess weiterverwenden. Den regulatorischen Rahmen beschreibt der Beitrag zur Testautomatisierung in regulierten Banken.

Was trägt Testautomatisierung zur Einstufung bei?

Testautomatisierung liefert der Triage reproduzierbare Belege für beide Einstufungen. 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 und entscheidet nicht über Schweregrad oder Priorität.

Was ein automatisierter Testlauf zur Triage beiträgt:

• Reproduzierbarkeit: Der visuelle Test-Workflow ist die Schrittfolge. Der exportierte Playwright- oder Appium-Code läuft außerhalb von Autemos erneut.

• Ergebnisse in Jira: Testausführungen synchronisieren sich bidirektional mit Jira/Xray, die Triage findet die Ergebnisse in Jira (Jira/Xray-Integration).

• Saubere Abgrenzung: Jede Self-Healing-Aktion steht im Report und lässt sich prüfen, ablehnen oder zurückrollen. Ein geänderter Locator erscheint so als Änderung am Test und landet nicht als vermeintlicher Produktfehler in der Triage.

• Umgebung: Die Konfiguration pro Umgebung (DEV, TEST, STAGING, PROD) hält fest, wo der Fehler auftrat. Das hilft bei der Frage, ob Kunden betroffen sein können.

In der Pipeline wirken beide Werte erst, wenn Quality Gates sie als Kriterium nutzen, zum Beispiel: kein Release, solange ein Fehler der Stufe S1 (Mozilla) oder 1 - Critical (Azure DevOps) offen ist. Nach einem Hotfix für einen Fehler mit hoher Priorität prüft ein schneller Smoke-Test die Kernfunktionen, bevor das Team breiter testet.

Häufig gestellte Fragen

Wer legt den Schweregrad eines Fehlers fest?

Verbindlich legt die Triage den Schweregrad fest. Bei Mozilla setzt QA für selbst gemeldete oder reproduzierte Bugs einen Anfangswert, andere Meldende sollen das Feld auf dem Standardwert lassen. Triager können jeden Wert übersteuern, jede Änderung braucht einen begründenden Kommentar (Mozilla Firefox Source Docs, 2026).

Kann ein Fehler einen hohen Schweregrad und eine niedrige Priorität haben?

Ja, Microsoft beschreibt diesen Fall. Für einen seltenen Remote-Link, der eine Anwendung abstürzen lässt, schlägt Microsoft Severity 2 - High und Priority 3 vor (Microsoft Learn, 2026). Der Absturz wiegt schwer, ist aber selten, und andere Arbeit geht vor.

Ist ein CVSS-Score dasselbe wie die Priorität?

Nein, ein CVSS-Score misst den Schweregrad einer Sicherheitslücke auf einer Skala von 0.0 bis 10.0 (FIRST, 2024). Die Priorität ergibt sich erst aus dem Kontext: Erreichbarkeit des Systems, betroffene Daten, verfügbare Workarounds. Zwei Lücken mit gleichem Score können unterschiedlich dringend sein.

Wie oft werden Schweregrad und Priorität nachträglich geändert?

Eine belegte Zahl nur für den Schweregrad gibt es nicht. Xia et al. fanden in 190 558 Fehlerberichten aus 4 Open-Source-Projekten, dass bei rund 80 % mindestens ein Feld neu zugewiesen wurde (Xia et al. 2014, zusammengefasst in Xia et al. 2016). Diese Quote umfasst alle Felder zusammen, die Komponente eingeschlossen.

Kann KI den Schweregrad automatisch bestimmen?

Teilweise. Lamkanfi, Demeyer, Giger und Goethals sagten Schweregrade per Text-Mining voraus und erreichten mit rund 500 Berichten pro Stufe Präzision und Recall von 0,65 bis 0,75 für Mozilla und Eclipse (Lamkanfi et al., MSR, 2010). Autemos macht keine solche Vorhersage, die Einstufung bleibt bei der Triage.

Fazit

Schweregrad und Priorität gehören in jeden Fehlerbericht, in getrennte Felder mit getrennten Verantwortlichen. Der erste Wert beschreibt die Auswirkung auf Entwicklung, Test oder Betrieb. Der zweite ist eine Entscheidung nach festgelegten Kriterien, und diese Kriterien muss das Team aufschreiben.

Für die Praxis bleiben drei Punkte:

• Eine Skala mit 4 klar beschriebenen Stufen und Beispielen aus dem eigenen Produkt.

• Eine feste Triage-Runde, in der jede Änderung am Schweregrad begründet wird.

• Reproduzierbare Belege aus dem Testlauf, damit die Einstufung auf Fakten beruht.

DORA verlangt von EU-Finanzunternehmen bei IKT-Vorfällen ebenfalls eine Klassifizierung nach Priorität und Schwere. Wenn Sie sehen möchten, wie Testergebnisse aus Autemos über Jira/Xray in Ihre Triage fließen, sprechen Sie mit unserem Team.