Warum der Titel mehr zählt als der Rest des Reports
Ein guter Bug-Titel = wo es passiert ist + was du gemacht hast + was schiefging + unter welcher Bedingung es auftritt. Stehen alle vier Punkte in einer Zeile, kann ein Entwickler den Fehler reproduzieren, ohne nachzufragen. Genau das ist der Unterschied zwischen einem guten und einem schlechten Titel. Unten findest du 40 Beispiele im direkten Vergleich, verteilt auf sieben Szenarien — Login, Registrierung, Zahlung, Mobile, APIs, Performance und UI — damit du deine eigenen Bugs daran umschreiben kannst.
Entwickler scannen zuerst den Titel — jedes Mal. Ein vager Titel bedeutet entweder eine zusätzliche Fragerunde oder das Ticket wird übersprungen. Schlimmer noch: Ein schlechter Titel lässt sich durch einen hervorragenden Umgebungsblock nicht retten — niemand öffnet ein Ticket namens „Button kaputt".
Ein Titel besteht oder scheitert an vier Punkten: Ist er spezifisch (nennt Komponente oder Seite), ist er beobachtbar (beschreibt Fakten statt „funktioniert nicht"), enthält er Bedingungen (Browser, Gerät, Kontotyp, Zeitpunkt) und erlaubt er eine Einschätzung des Umfangs (Totalausfall oder Randfall)?
Die 4-teilige Formel für Bug-Titel
[Komponente/Seite] + [Aktion] + [unerwartetes Ergebnis] + [Bedingung]
So füllst du die Bausteine:
- Komponente: Checkout-Seite / Login-Modal / Bestellliste /
POST /api/orders - Aktion: klicken, absenden, hochladen, Tab wechseln, scannen
- Unerwartetes Ergebnis: keine Reaktion, 500 zurückgegeben, Wert um eine Stelle zu hoch, Status nicht synchronisiert, Text überlappt
- Bedingung: Chrome 120, iOS 17.2, Breite <390px, nur Enterprise-Konten, nach einem Netzwerk-Timeout
Sentence Case, Komponente zuerst, keine Prioritäts-Tags. Auf diese Konvention einigen sich die meisten Teams — und Konsistenz ist wichtiger als die Wahl der Konvention.
1. Login und Konten (7 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Login-Button funktioniert nicht | Klick auf „Anmelden" in Chrome 120 löst nichts aus; Konsole wirft TypeError: login is not a function |
| Passwort-Reset-Mail kommt nicht an | Keine Reset-Mail nach Klick auf „Passwort vergessen" mit einer Gmail-Adresse (Spam nach 30 Minuten geprüft) |
| Falsche Weiterleitung nach Login | Standardnutzer landet nach dem Login auf /admin statt /dashboard; reproduzierbar seit v5.3 |
| Captcha schlägt ständig fehl | Gültiges Captcha wird weiterhin mit „Ungültiger Code" abgelehnt — nur in privaten bzw. Inkognito-Fenstern |
| Konto wird gesperrt | Drei Fehlversuche sperren das Konto dauerhaft, die Meldung sagt aber „in 24 Stunden erneut versuchen" |
| Session wird nicht ungültig | Anmeldung auf einem zweiten Gerät beendet die erste Session nicht; sie bleibt voll nutzbar |
| SSO-Login schlägt fehl | SSO-Callback liefert „Invalid signature", seit dem Zertifikatswechsel beim IdP |
Kernaussage: Bei Login-Bugs entscheidet die Bedingung (Browser, Kontotyp, Inkognito) darüber, ob überhaupt jemand reproduzieren kann. Nicht weglassen.
2. Registrierung und Formulare (7 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Registrierung funktioniert nicht | Registrierung lehnt E-Mail-Adressen mit „+" ab (z. B. user+test@x.com) und meldet „Ungültiges E-Mail-Format" |
| Telefonnummer wird nicht akzeptiert | Eine vollständige 11-stellige Nummer löst weiterhin „Bitte 11-stellige Nummer eingeben" aus |
| Passwortstärke-Anzeige ist falsch | Ein 8-stelliges Passwort, das bereits Ziffern enthält, zeigt weiterhin „muss eine Zahl enthalten" |
| Dropdown lässt sich nicht auswählen | Länder-Dropdown lässt sich nach Filterung über 3 Zeichen nicht mehr per Pfeiltasten auswählen |
| Formular sendet doppelt | Enter im Registrierungsformular sendet zweimal; es entstehen zwei doppelte Nutzerdatensätze |
| Pflichtfeld wird nicht geprüft | Registrierung gelingt ohne Häkchen bei „AGB akzeptieren"; das Konto wird trotzdem erstellt |
| Falsche Zeitzone als Standard | Zeitzone steht standardmäßig auf UTC+0; Nutzer in UTC+8 müssen sie bei jeder Registrierung manuell ändern |
Kernaussage: Ersetze Beschreibungen durch konkrete Eingabewerte. Eine echte Zeichenkette bringt mehr als zehn Sätze „Eingabe funktioniert nicht".
3. Zahlung und Checkout (7 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Zahlung schlägt fehl | Bestellsumme von 129,99 € wird im Checkout als 1.299,99 € angezeigt (eine Stelle zu viel); die Zahlungsseite übernimmt den falschen Betrag |
| Gutschein funktioniert nicht | Abgelaufener Gutschein wird weiterhin als „gültig" angezeigt; Anwenden liefert 500 und leert den Warenkorb |
| Warenkorb-Zähler aktualisiert nicht | Zähler im Header zeigt nach Entfernen des letzten Artikels weiter „1"; erst ein Reload korrigiert ihn |
| Doppelte Abbuchung | Erneuter Zahlungsversuch nach Netzwerk-Timeout bucht dieselbe Bestellung zweimal ab (Bestellung #10231) |
| Rechnungsdaten werden nicht gespeichert | Firmen-Rechnungsdaten werden beim Zurückgehen und erneuten Vorwärtsgehen gelöscht |
| Erstattungsstatus nicht synchron | Bestellung zeigt in der Kundenansicht weiter „Bezahlt", obwohl die Erstattung ausgeführt wurde (Bestellung #10388) |
| Zahlungsart fehlt | Kartenzahlung fehlt im Checkout — nur bei Konten mit dem alten Abrechnungsmodell |
Kernaussage: Bei allem, was Geld oder Bestellnummern betrifft, gehört die Bestellnummer in den Titel. Das halbiert die Triage-Zeit.
4. Mobile und Responsive (6 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Layout auf dem Handy kaputt | Button „In den Warenkorb" überlappt den Preis auf iPhone 14 (iOS 17.2) unter 390px Breite |
| Seite lässt sich nicht scrollen | Öffnen eines Modals sperrt das Scrollen auf Mobile; nach dem Schließen bleibt es gesperrt |
| Eingabefeld von Tastatur verdeckt | Android-Chrome-Tastatur verdeckt den „Absenden"-Button; er ist nicht antippbar |
| Querformat-Layout kaputt | Navigationsleiste bricht auf dem iPad im Querformat (1024×768) um; Logo überlappt das Menü |
| Bilder laden nicht | Produkt-Hauptbild fehlt in Safari iOS 16; Konsole liefert 403 (abgelaufene CDN-Signatur) |
| Tippfläche zu klein | Paginierungs-Buttons auf Mobile haben eine Tippfläche von 12×12px — unter dem Barrierefreiheits-Minimum von 44px |
Kernaussage: Auf Mobile ist „Mobile" keine Bedingung. Schreibe exaktes Modell, OS-Version und Viewport-Breite.
5. Daten, APIs und Berechtigungen (6 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Export schlägt fehl | Export von mehr als 10.000 Bestellungen liefert 504; batchweiser Export funktioniert |
| Falsche Zeitstempel | Zeitstempel im Report liegen 8 Stunden zurück — nur bei Nutzern in der Zeitzone Asia/Shanghai |
| Suche liefert nichts | Suche nach „iPhone" liefert 0 Treffer, obwohl 12 passende Datensätze in der Datenbank existieren |
| Doppelte Zeilen beim Blättern | Bestellliste wiederholt die letzten 3 Zeilen von Seite 1 am Anfang von Seite 2 |
| Upload-Fehler | PNG-Uploads über 5MB liefern 413, die UI meldet aber „Upload abgeschlossen" bei leerer Datei |
| Rechteausweitung | Nur-Lese-Rolle kann DELETE /api/projects/12 aufrufen und ein Projekt erfolgreich löschen |
Kernaussage: Bei API-Bugs gehören HTTP-Statuscode, Endpunkt-Pfad oder Schwellenwert in den Titel. Das ist die halbe Debug-Arbeit im Voraus.
6. Performance und Ladezeit (3 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Seite ist langsam | Startseite hat LCP 8,2s im 4G-Netz, verursacht durch 2,1MB unkomprimiertes JavaScript |
| Speicherleck | Speicher wächst nach 20 Tab-Wechseln von 120MB auf 900MB; danach stürzt der Tab ab |
| API ist langsam | P95 des Produktlisten-Endpunkts liegt bei 4,8s (Basis 300ms) — nur zu Spitzenzeiten im Sale |
Kernaussage: Performance-Bugs brauchen eine Zahl und einen Basiswert, sonst kann niemand beurteilen, ob es überhaupt ein Defekt ist.
7. Texte und UI-Details (4 Beispiele)
| Schwacher Titel | Starker Titel |
|---|---|
| Tippfehler auf der Seite | „Bestätgung" muss „Bestätigung" heißen — auf der Bestellbestätigung |
| Icons inkonsistent | Zwei der vier Icons auf der Einstellungsseite sind Line-Style, zwei sind Filled-Style |
| Dark Mode unlesbar | Im Dark Mode ist der Eingabetext #333 auf dunklem Hintergrund und praktisch unsichtbar |
| Unbrauchbare Fehlermeldung | Fehlgeschlagener Upload zeigt nur „Vorgang fehlgeschlagen", ohne Ursache und ohne Hinweis zum Wiederholen |
Kernaussage: Bei Text- und UI-Bugs schreibst du „so steht es da → so sollte es heißen". Das ist der geringste Review-Aufwand aller Bug-Typen.
7 Gewohnheiten, die Titel schlechter machen
Wie verschiedene Rollen Titel schreiben sollten
| Rolle | Vorgehen |
|---|---|
| QA / Tester | Vollständige 4-teilige Formel, alle Bedingungen gefüllt (Browser, Gerät, Konto, Netzwerk) |
| Support oder Ops eskaliert | Nutzersichtbares Symptom + reproduzierbarer Pfad + Screenshot; Ursache weglassen, wenn unbekannt, und „offen für Dev-Prüfung" markieren |
| UAT-Review | Am Abnahmekriterium verankern: „Verstößt gegen AC-3: Bestellstatus nicht innerhalb von 5 Sekunden aktualisiert" |
| Produktmanagement | Nutzersichtbare Auswirkung für die Priorisierung beschreiben, aber das technische Symptom nicht ersetzen |
Wenn ein Titel übersetzt wird
| Titel in Ausgangssprache | Deutscher Titel |
|---|---|
| 结算页删除最后一件商品后购物车角标未更新 | Warenkorb-Zähler wird nach dem Entfernen des letzten Artikels im Checkout nicht aktualisiert |
| Android Chrome 键盘遮挡提交按钮，无法点击 | Android Chrome: Tastatur verdeckt den Absenden-Button, er ist nicht antippbar |
| 只读角色可删除项目（越权） | Nur-Lese-Rolle kann Projekte löschen (Rechteausweitung) |
Drei Regeln, wenn ein Titel die Sprache wechselt: Komponentennamen in der Originalsprache behalten, wenn es Eigennamen sind; das beobachtbare Ergebnis wörtlich übersetzen; Log-Meldungen und Fehlercodes niemals übersetzen. Ein übersetzter Stacktrace ist ein nicht reproduzierbarer Bug.
FAQ
Wie lang sollte ein Bug-Titel sein? Ungefähr unter 60 Zeichen bzw. 10 Wörtern, damit er in Listenansichten nicht abgeschnitten wird. Passt es nicht, wurde entweder das Kernsymptom nicht herausgearbeitet oder es sind zwei Bugs.
Gehören Priorität oder Schweregrad in den Titel? Nein. Priorität ist ein eigenes Feld und ändert sich mit der Planung. Danach ist der Titel falsch — und er verschmutzt die Suche.
Darf ich eine Vermutung in den Titel schreiben, wenn ich die Ursache nicht kenne? „Vermutlich verursacht durch X" ist erlaubt, aber nie als festes Ergebnis. Begründe es im Text, sonst führst du das Triage in die falsche Richtung.
Ein Bug in mehreren Browsern — mehrere Tickets? Titel = Kernsymptom, Umgebungsunterschiede ins Umgebungs- oder Notizfeld. Nur trennen, wenn die Fix-Pfade wirklich unterschiedlich sind, etwa getrennte iOS- und Android-Codepfade.
Title Case oder Sentence Case? Beides ist möglich, aber bleib konsistent mit dem bestehenden Backlog. Ohne Altlasten liest sich Sentence Case besser und ist schneller zu erfassen.
Den Titel schreibst weiterhin du — alles andere kann automatisch gehen
Um es klar zu sagen: BugCapturer schreibt deinen Titel nicht — dafür braucht es deine Einschätzung dessen, was du gesehen hast. Die mühsamen, leicht vergessenen Felder können sich aber selbst füllen:
- Automatischer technischer Kontext: URL, Browser, Betriebssystem, Bildschirmauflösung und Viewport werden erfasst, damit die Bedingungen im Titel nie per Hand abgetippt werden müssen.
- Diagnosedaten: Konsolen-Logs auf Fehlerlevel und fehlgeschlagene Netzwerkanfragen (HTTP ≥ 400) werden gesammelt, sensible Parameter (Tokens, Passwörter, API-Keys) automatisch unkenntlich gemacht.
- Annotierte Screenshots: Bereich per Drag markieren und Pfeile, Rahmen und Text ergänzen — „wo es falsch ist" steckt im Bild fest.
- Bildschirmaufnahme: Aktuellen Tab aufnehmen und den Ausschnitt kürzen; Entwickler bekommen ein 12-Sekunden-Video zur Verifikation.
- Ein-Klick-Teilen oder Synchronisieren: Einen Freigabelink erzeugen, den externe Mitwirkende ohne Registrierung öffnen können, oder den Report in eine Feishu-Base bzw. einen generischen Webhook schicken.
So musst du nur diese eine Titelzeile richtig hinbekommen, den Rest füllt das Tool.
Checkliste zum Herunterladen
Klebe sie neben den Monitor und gehe sie vor dem Absenden durch:
- Wird die Komponente oder Seite genannt?
- Steht dort ein beobachtbarer Fakt statt „funktioniert nicht"?
- Enthält der Titel Bedingungen (Browser / Gerät / Konto / Netzwerk / Breite)?
- Enthält er eine überprüfbare Zahl (Statuscode, Bestellnummer, Betrag, Dauer, Schwellenwert)?
- Beschreibt er genau ein Symptom?
- Sind Priorität und unbestätigte Vermutungen entfernt?
- Bleibt er unter etwa 60 Zeichen bzw. 10 Wörtern?
Alle sieben erfüllt — und deine Titel werden vor 90 % des Backlogs triagiert.
Weiterlesen: Bug-Bericht-Vorlage (vollständige Feldliste und kopierfertige Vorlage) · Bugs effektiv melden · Testfall-Vorlage mit Beispielen · Bug-Berichtsformat · Reproduktionsschritte schreiben