Modul 07 · QS in der Praxis
Ein Fehler-Ticket schreiben
Was du danach weißt: Was ein gutes Bug-Ticket enthält — und warum ein präzises
Ticket der Unterschied ist zwischen einem Fix im nächsten Release und
monatelangen Rückfragen.
Das Problem mit vagen Tickets
Entwickler können nur reparieren, was sie reproduzieren können.
Wenn sie den Fehler auf ihrem System nicht nachstellen können,
beginnt ein Ping-Pong aus Rückfragen — und das kostet Zeit,
die vielleicht nicht mehr in den nächsten Release passt.
„Gehalt von Mitarbeiter Huber ist falsch berechnet. Bitte prüfen."
Welcher Huber? Welcher Monat? Wie viel ist falsch?
Was wäre richtig gewesen? Welche Kundenumgebung?
→ Entwickler fragt zurück, du antwortest, Entwickler schaut, fragt nochmals…
Titel, Schritte, erwartetes Ergebnis, tatsächliches Ergebnis, Kontext.
Entwickler öffnet Ticket, kann den Fehler sofort nachstellen,
findet die Ursache, behebt sie.
Kein Ping-Pong.
Die fünf Felder eines guten Tickets
Ein Bug-Ticket braucht fünf Informationen. Alles andere ist optional.
Titel
Kurz und spezifisch — was ist falsch, wo, wann?
Nicht: „Gehalt falsch" — sondern: „Teilmonatseintritt Mai: Berechnung auf 30 statt 31 Tage"
Schritte
Konkrete Schritt-für-Schritt Anleitung zum Nachstellen des Fehlers
Erwartet
Was hätte das System ausgeben sollen — mit konkreter Zahl wenn möglich
Tatsächlich
Was das System stattdessen ausgegeben hat — mit konkreter Zahl
Kontext
Kundenname (oder anonymisiert), Release-Version, Kollektivvertrag, betroffene Mitarbeiterzahl
Ein vollständiges Beispiel
Titel
Teilmonatseintritt: Brutto-Aliquotierung basiert auf 30 statt 31 Tagen im Mai 2026
Schritte
- Neuen Mitarbeiter anlegen: Vollzeit, Brutto 3.000 €, Eintritt 15.05.2026, KV Handel
- Abrechnungslauf Mai 2026 starten
- Lohnzettel des Mitarbeiters aufrufen → Zeile „Brutto aliquot" prüfen
Erwartet
3.000 € ÷ 31 × 17 = 1.645,16 € (Mai hat 31 Tage)
Tatsächlich
3.000 € ÷ 30 × 17 = 1.700,00 € ✗ (System rechnet mit 30)
Kontext
Kunde Muster GmbH, Release 26.2, betrifft alle Eintritte im Mai mit 31-Tage-Monaten
Dasselbe Ticket auf Englisch
Das Entwickler-Team bei P&I arbeitet auf Englisch.
Du wirst Tickets auf Englisch schreiben — die fünf Felder sind dieselben,
nur die Sprache wechselt. Inhalt und Zahlen bleiben identisch.
Title
Partial-month entry: gross salary pro-rated on 30 instead of 31 days (May 2026)
Steps to Reproduce
- Create new employee: full-time, gross salary €3,000, entry date 15 May 2026, collective agreement "Handel"
- Run May 2026 payroll
- Open employee's payslip → check line "Gross salary (pro-rated)"
Expected
€3,000 ÷ 31 × 17 = €1,645.16 (May has 31 days)
Actual
€3,000 ÷ 30 × 17 = €1,700.00 ✗ (system calculates with 30)
Context
Customer: Muster GmbH · Release 26.2 · affects all entries in May (31-day months)
Die fünf Felder auf Englisch — zum Nachschlagen:
| Titel |
Title oder: Summary |
| Schritte |
Steps to Reproduce |
| Erwartet |
Expected Result |
| Tatsächlich |
Actual Result |
| Kontext |
Context oder: Environment |
In deiner Arbeit bei P&I
Verbindung zu Modul 05: Given/When/Then war für Anforderungen —
was soll gebaut werden? Ein Bug-Ticket ist die andere Seite:
was ist gebaut, aber falsch?
Die Logik ist dieselbe: Ausgangssituation → Aktion → Ergebnis.
Nur dass bei einem Bug „Erwartet" und „Tatsächlich" auseinanderfallen.
P&I veröffentlicht dreimal pro Jahr ein Release.
Ein Bug dessen Ticket unklar ist, kommt nicht in den nächsten Release —
weil der Entwickler zuerst Rückfragen schickt und die Zeit vergeht.
Ein vollständiges Ticket kann sofort bearbeitet werden.
Denke mal nach:
Welches Kundenproblem aus deinem Alltag wäre schwierig als Ticket zu beschreiben —
weil es schwer reproduzierbar ist? Was würdest du tun, wenn du den Fehler
nicht gezielt nachstellen kannst?