Ein Bug ist das umgangssprachliche Wort für einen Defect; ein Defect ist der formale Begriff für jede Abweichung, bei der die Software ihre Anforderung nicht erfüllt. Ein Issue ist der Oberbegriff für Defects, Feature-Requests, Aufgaben und Fragen. Praktisch beschreiben sie dasselbe auf unterschiedlichen Förmlichkeitsstufen — und die Mischung innerhalb eines Teams ist das, was Verwirrung erzeugt.
Die Unterschiede zählen weniger im Gespräch als an drei Stellen: was ihr messt, was ihr vertraglich zusagt und was ihr eine meldende Person ausfüllen lasst. Diese Seite liefert eine belastbare Trennung, die ihr ins Glossar schreiben und dann nicht mehr diskutieren müsst.
Die Kurzfassung
| Begriff |
Umfang |
Wo er auftaucht |
| Bug |
Umgangssprachlich für Defect. Meist etwas, das früher funktionierte oder offensichtlich funktionieren müsste |
Daily, Chat, „da ist ein Bug im Checkout" |
| Defect |
Formal: jede Abweichung zwischen tatsächlichem und erwartetem Verhalten, unabhängig davon, ob es je funktionierte |
QA-Berichte, Audits, Verträge, Kennzahlen |
| Issue |
Oberbegriff: alles, was eine Entscheidung braucht — Defect, Feature-Request, Aufgabe, Frage |
Tracker, Ticket-IDs, Release Notes |
| Error |
Eine menschliche Handlung, die zu einem falschen Ergebnis führt |
Ursachenanalyse, Post-Mortems |
| Fault |
Die fehlerhafte Anweisung oder Datendefinition in der Software, die den Fehler verursacht |
Engineering-Diskussion, Standards |
| Failure |
Das beobachtbare Ereignis: Das System tut nicht, was es muss |
Incident-Reviews, Monitoring |
Wenn ihr euch nur eine Zeile merkt: Error → Fault → Failure ist eine Kausalkette, und Defect ist das, was ihr erfasst — meist ein Fault. Bug ist das, was Leute laut sagen.
Die Kette: Error, Fault, Failure
Das klassische Modell, weiterhin in Standards und in Post-Mortems nützlich:
Error — ein Mensch macht einen Fehler: missverstandene Anforderung, falsche Annahme, übersprungene Prüfung.
Fault — dieser Fehler wird zu einem konkreten Defekt in Code, Konfiguration oder Daten.
Failure — der Fault läuft unter passenden Bedingungen und wird sichtbar: Seite bricht, Summe falsch, Speichern scheitert still.
Diese Kette erklärt, warum „menschliches Versagen" allein nie eine Ursache ist. Sie erklärt die Entstehung eines Defekts, nicht warum er in Produktion gelangte. Für die QA-Sicht auf Klassifikation und Priorisierung siehe den Leitfaden zur Defect-Triage.
Warum „Issue" das bessere Wort für euren Tracker ist
Ein Tracker hält mehr als Defekte. Nennt das Objekt Issue — und behaltet „Bug" als Alltagswort — und ihr habt einen Ort für:
- Defects (Verhalten ist falsch),
- Feature-Requests (Verhalten fehlt absichtlich),
- Aufgaben (Arbeit ohne Verhaltensbezug),
- Fragen (keine Codeänderung erwartet).
Die Falle ist ein Tracker mit nur einem Typ „Bug". Teams reichen dann Feature-Requests als Bugs ein, um in die Warteschlange zu kommen, und das korrumpiert eure Defect-Kennzahlen dauerhaft — ihr könnt nicht mehr unterscheiden, ob die Qualität steigt oder nur umetikettiert wurde.
Wenn ihr ein Tool auswählt, deckt der Leitfaden zum Issue-Tracking-System die weiteren Kriterien ab; für den QA-Lebenszyklus siehe Defect-Management-Software.
Wo die Unterscheidung Geld verdient
1. Verträge und SLAs. Eine Support-Vereinbarung, die „kritische Defects in 24 Stunden behoben" verspricht, braucht eine schriftliche Definition von Defect und kritisch. Ohne sie ist jede Diskussion eine Verhandlung. „Bug" im Vertrag ist meist zu vage, um durchsetzbar zu sein.
2. Kennzahlen. Defektdichte, Escape Rate und Wiedereröffnungsrate bedeuten nur etwas, wenn die Grundgesamtheit stabil ist. Sind die Hälfte eurer „Bugs" Feature-Requests, halten keine der Zahlen.
3. Audit und Compliance. Regulierte Produkte brauchen meist einen nachvollziehbaren Defect-Datensatz mit Schweregrad, Verifikation und Abschlussbelegen. Das ist ein formales Artefakt — das Wort Defect signalisiert diese Formalität.
Bug vs. Feature-Request
Die Trennlinie, die die meisten Diskussionen erzeugt:
| Ein Defect ist es, wenn … |
Ein Feature-Request ist es, wenn … |
| Das Verhalten einer schriftlichen Anforderung oder dem dokumentierten Design widerspricht |
Keine Anforderung existiert und das Verhalten nie zugesagt wurde |
| Nutzer eine Aufgabe nicht mehr erledigen können, die vorher ging |
Nutzer die Aufgabe erledigen können, nur nicht so, wie sie es bevorzugen |
| Der Systemzustand inkonsistent wird oder Daten verloren gehen |
Das System konsistent ist und die Ausgabe nur nicht gewünscht war |
| Barrierefreiheit, Sicherheit oder Datenintegrität betroffen sind |
Es eine Präferenz zu Layout, Text oder Ablauf ist |
Schwierig sind Fälle, die „per Konvention" erwartet werden. Ein deaktivierter Button ohne Feedback ist in den meisten Designsystemen ein Defect, auch wenn keine Anforderung das sagt. Entscheidet solche Fälle mit einer schriftlichen Regel, sonst diskutiert ihr sie jeden Sprint neu.
Bug vs. Error (die Meldung auf dem Bildschirm)
Eine Fehlermeldung auf dem Bildschirm ist für sich kein Defect. „E-Mail-Format ungültig" ist korrektes Verhalten. Der Defect ist der Fall, in dem die Meldung falsch, fehlend oder unangebracht ist. Und das Error in „Console error" meint eine vom Runtime protokollierte Ausnahme — die ein Defect sein kann oder auch nicht (viele geloggte Fehler sind erwartet und behandelt). Genau deshalb sollte ein Bericht die Console-Ausgabe als Text mitbringen statt als Screenshot: Wer triagiert, braucht Text, Stack und Häufigkeit, kein Bild.
Ein Vokabular wählen und aufschreiben
Die Empfehlung, mit der die meisten Teams leben können:
- Issue ist das Objekt im Tracker. Alle Typen leben darunter.
- Defect ist der Typ für falsches Verhalten und das Wort für Kennzahlen, Verträge, Berichte.
- Bug bleibt das gesprochene Wort. Aus Dashboards verbannen.
- Error / Fault / Failure nur in der Ursachenanalyse, in dieser Reihenfolge.
Schreibt das in ein Fünf-Zeilen-Glossar im QA-Dokument, zusammen mit der Defect-vs-Feature-Regel. Es geht nicht um Sprachreinheit, sondern darum, dass ein stabiles Vokabular Berichte wiederverwendbar und Kennzahlen von Monat zu Monat vergleichbar macht.
Was das für den Bericht bedeutet
Wie ihr es auch nennt, die Felder für die Triage sind identisch:
- die genaue Seite oder der Endpunkt,
- was getan wurde und was erwartet war gegenüber dem, was passierte,
- die Belege: Screenshot, Console-Fehler, fehlgeschlagene Requests,
- die Umgebung: Browser, OS, Viewport, Zeitstempel.
Das ist der Unterschied zwischen einem Bericht, der in zwei Minuten klassifiziert ist, und einem, der ein fünfzehnminütiges Verhör startet. Das Bug-Report-Format behandelt jedes Feld, die Titelbeispiele zeigen, wie die erste Zeile suchbar wird.
FAQ
Ist ein Bug dasselbe wie ein Defect?
Im Alltag ja. Formal ist ein Defect die Abweichung vom erwarteten Verhalten und Bug der umgangssprachliche Name. Verträge und Audits nutzen Defect, weil er definiert ist; Teams sagen Bug, weil es kürzer ist.
Ist ein Defect dasselbe wie ein Failure?
Nein. Ein Defect ist ein Mangel, der in der Software existiert; ein Failure ist das beobachtbare Ereignis, wenn er unter passenden Bedingungen ausgeführt wird. Ein Defect kann Jahre im Code liegen, ohne je einen Failure zu verursachen.
Soll unser Tracker „Bug" oder „Issue" sagen?
Objekt Issue, mit Defect als einem Typ. Ein Tracker mit nur dem Typ „Bug" zwingt Feature-Requests in die Defect-Warteschlange und korrumpiert die Qualitätskennzahlen.
Wo passt „Error" hin?
Ein Error ist eine menschliche Handlung, die einen Fault einführt. Er ist eine Ursache, keine Ticketkategorie. „Menschliches Versagen" als Ursache beendet die Analyse einen Schritt zu früh.
Müssen wir das mit Tooling erzwingen?
Nur leicht. Ein Pflichtfeld „Typ" und eine schriftliche Definition von Defect gegenüber Feature-Request genügen. Mehr Taxonomie dokumentiert meist nur gründlicher die falsche Sache.