Ein Issue-Tracking-System ist das eine zentrale Register, in dem jedes Problem, jeder Defekt und jede Anfrage erfasst, zugewiesen und geschlossen wird — entschieden wird die Wahl an vier Punkten: wie Issues hineinkommen, wie sie sich bewegen, wer sie sehen darf und was es bei eurer Lizenzanzahl kostet.
Viele Teams wählen nach Feature-Listen und merken ein halbes Jahr später: Das Tool ist in Ordnung, kaputt ist der Eingang. Issues treffen als Chat-Nachricht ein, als Screenshot in irgendeinem Ordner, als „kannst du mal schauen?". Niemand kann sagen, wie viele offen sind, und im Register steht nur, was jemand freiwillig noch einmal abgetippt hat.
Dieser Leitfaden deckt beide Hälften ab: die neun Kriterien, die die Entscheidung wirklich bestimmen, und den Eingangsschritt, den fast jede Vergleichsseite auslässt.
Was ein Issue-Tracking-System tatsächlich ist
Ein Issue-Tracking-System (auch Issue Tracker oder Issue-Management-System; bei engerem Zuschnitt Bug-Tracking- oder Defect-Tracking-System) erledigt vier Aufgaben:
- Erfassen: ein Problem so festhalten, dass jemand anderes damit arbeiten kann.
- Zuweisen: einen Verantwortlichen benennen und die Zuständigkeit sichtbar machen.
- Verfolgen: einen Status von neu bis geschlossen führen, mit Historie darüber, wer was geändert hat.
- Auswerten: beantworten, wie viele offen sind, wie alt sie sind und wo sie sich stauen.
Boards, Sprints, Roadmaps, SLAs und Automatisierung sind Schichten darüber. Ist Erfassung und Auswertung schwach, rettet keine Board-Design das System.
Issue-Tracking-System vs. Bug-Tracker vs. Helpdesk
Die Begriffe überlappen, Anbieter verwenden sie locker. Der praktische Unterschied ist der Umfang:
| System |
Typischer Umfang |
Meist verantwortet von |
| Issue-Tracking-System |
Alles, was eine Entscheidung braucht: Defekte, Aufgaben, Anfragen, Fragen |
Produkt oder Entwicklung |
| Bug-Tracker / Defect-Tracker |
Nur Defekte, meist an Build oder Testzyklus gebunden |
QA |
| Helpdesk / Service Desk |
Eingehende Anfragen von Nutzern mit Reaktionszeiten |
Support oder IT |
| Testmanagement-Tool |
Testfälle, Läufe, Ergebnisse — Defekte daran verknüpft |
QA |
Wählt nach Umfang, nicht nach Anbieterkategorie. Wer mit einem Bug-Tracker startet, braucht meist innerhalb eines Jahres ein Issue-Tracking-System; wer mit einem vollen Service Desk startet, bereut die Zeremonie.
Wenn du gezielt die Defect-Lifecycle-Sicht brauchst — Schweregrad, Verifikation, Regression — lies stattdessen den Vergleich von Defect-Management-Software. Diese Seite behandelt das allgemeine Register.
Die 9 Kriterien, die die Wahl entscheiden
Sortiert diese Punkte bevor ihr eine Testphase startet. Die Reihenfolge ist wichtiger als die Antworten.
| # |
Kriterium |
Warum es den Ausgang bestimmt |
Worauf achten |
| 1 |
Eingang |
Das Register ist nur so gut wie das, was hineinkommt |
Kann eine nicht-technische Person mit einem Klick einreichen? Kommt der Bericht mit Screenshot, Console-Fehlern, fehlgeschlagenen Requests und Browser/OS/Viewport? |
| 2 |
Workflow |
Starre Workflows werden umgangen, lockere verstecken den Status |
Lässt sich ein Status ohne Berater ergänzen? Werden Übergänge protokolliert? |
| 3 |
Felder |
Schweregrad und Priorität sind nicht dasselbe Feld |
Severity (technische Wirkung) und Priority (Geschäftsdringlichkeit) getrennt? Eigene Felder pro Projekt? |
| 4 |
Duplikaterkennung |
Duplikate sind der Hauptgrund, warum Triage stockt |
Suche beim Tippen über Titel und Seiten-URL? Zusammenführen mit erhaltener Historie? |
| 5 |
Ausgehende Integrationen |
Das Register muss dort ankommen, wo Menschen ohnehin arbeiten |
Chat (Slack / Teams), Versionsverwaltung, Release Notes plus ein generischer Webhook für alles andere |
| 6 |
Berechtigungen |
Externe Melder dürfen euer Backlog nicht sehen |
Gastrolle nur für eigene Issues? Sichtbarkeit pro Projekt? |
| 7 |
Auswertung |
Ohne Alterskennzahlen führt man die Warteschlange nicht |
Offene nach Alter, Last pro Person, Wiedereröffnungsrate, Cycle Time — exportierbar |
| 8 |
Kosten bei eurer Lizenzanzahl |
Die Lizenzrechnung ändert die Antwort stärker als Features |
Preis bei 5, 20 und 50 Lizenzen; was zählt als Lizenz (Leser? Gäste? Melder?) |
| 9 |
Ausstieg |
Ihr werdet mindestens einmal migrieren |
Voller Export inklusive Anhänge und Kommentare? Offene API? |
Eine Shortlist, die Kriterium 1 ignoriert, sieht in der Demo großartig aus und scheitert in Woche drei.
9 Issue-Tracking-Systeme im Vergleich (2026)
Preismodelle sind nach Form beschrieben, nicht mit exakten Beträgen — Listenpreise ändern sich und regionale Preise unterscheiden sich. Prüft die aktuellen Zahlen beim Anbieter.
| Tool |
Am besten für |
Issues kommen über |
Preismodell |
Aufpassen bei |
| Jira (Atlassian) |
Teams mit konfigurierbaren Workflows, bereits im Atlassian-Stack |
Formulare, E-Mail, Integrationen |
Kostenlose Stufe, dann Abo pro Lizenz |
Konfigurationsschuld; eine Admin-Rolle entsteht schnell |
| Linear |
Produktteams, die Tempo und Tastatur-Triage wollen |
Manuell, Slack, Integrationen |
Abo pro Lizenz |
Bewusst meinungsstark; weniger für Nicht-Engineering-Warteschlangen |
| GitHub Issues |
Arbeit direkt am Repository |
Manuell, Templates, API |
In Repository-Plänen enthalten |
Schwach bei Nicht-Code-Anfragen und projektübergreifender Auswertung |
| GitLab |
Teams, die Issues, Merge Requests und CI an einem Ort wollen |
Manuell, Templates, API |
Gestufte Abos, kostenlose Self-Managed-Variante |
Funktionsgrenzen zwischen den Stufen |
| YouTrack (JetBrains) |
Teams mit query-getriebenen Ansichten und eigenen Workflows |
Manuell, E-Mail, Integrationen |
Abo pro Lizenz, kostenlos für kleine Teams |
Dichte Oberfläche; Einstiegshürde für nicht-technische Melder |
| Azure DevOps Boards |
Microsoft-Stack-Teams mit Testplänen und Pipelines |
Manuell, Pipelines, Integrationen |
Abo pro Nutzer |
Lohnt nur, wenn ihr den Rest von Azure DevOps auch nutzt |
| Bugzilla |
Langfristige Projekte mit bewährter, selbst gehosteter Defektdatenbank |
Manuell, E-Mail |
Kostenlos, Open Source |
Veraltete Oberfläche; Reporting braucht Erweiterungen |
| Redmine |
Teams mit Sysadmin, die Module und volle Kontrolle wollen |
Manuell, E-Mail |
Kostenlos, Open Source |
Plugin-Wildwuchs; Upgrades sind echte Arbeit |
| MantisBT |
Kleine Teams mit einfachem, selbst gehostetem Tracker |
Manuell, E-Mail |
Kostenlos, Open Source |
Wenig Automatisierung, wenige moderne Integrationen |
Keines davon ist schlecht. Das Scheitern passiert, wenn man wegen der Workflow-Engine wählt und den Eingang bei Copy-and-paste lässt.
Der Schritt, den fast jede Auswahl überspringt: Wie das Issue hineinkommt
Jedes Tool oben setzt voraus, dass das Issue schon beschrieben ist. Genau dort geht die Zeit verloren:
- Ein Tester schreibt „Checkout-Button reagiert nicht", und die Entwicklung stellt drei Fragen, bevor sie die DevTools öffnet;
- ein Screenshot liegt im Chat-Thread, ohne Seiten-URL und Browser;
- der Console-Fehler, der alles erklärt, wurde nie erfasst, weil der Melder nicht weiß, was eine Console ist;
- der Bug ist nicht reproduzierbar, wird als „bei mir geht's" geschlossen und kommt zwei Sprints später zurück.
Vergleicht, was jeweils ankommt:
| Was ein Fix braucht |
Manueller Bericht |
Bericht mit automatischem Kontext |
| Wo es passierte |
„die Checkout-Seite, glaube ich" |
Exakte URL und Seitentitel |
| Was geklickt wurde |
Ein Satz in den Worten des Melders |
Annotierter Screenshot mit Markierung und Selektor |
| Was kaputt ist |
„es funktioniert nicht" |
Console-Fehler und fehlgeschlagene Requests, im Wortlaut |
| Umgebung |
„Chrome, vielleicht ein Mac?" |
Browser, OS, Viewport, Zeitstempel |
| Wer es reproduzieren kann |
Niemand, bis der Melder wieder Zeit hat |
Jeder mit dem Link, sofort |
Genau diese Schicht deckt BugCapturer ab, und zwar bewusst nicht als Tracker: Tester erfassen per Browser-Extension (Screenshot, Annotation, Tab-Aufzeichnung), Besucher melden über ein eingebettetes Web SDK ohne Installation, und jeder Bericht trägt automatisch Console- und Netzwerk-Kontext. Berichte landen in Slack, Microsoft Teams, Lark Bitable oder eurem eigenen Webhook — die Eingangsschicht versorgt also den oben gewählten Tracker, statt mit ihm zu konkurrieren. Die kostenlose Stufe enthält eine Lizenz, drei Projekte und eine Integration, Console-Erfassung ist nie gated; den Rest findest du unter Preise.
Eine praktikable Aufteilung für die meisten Teams: Der Tracker entscheidet, die Eingangsschicht sammelt. Der Tracker hält Status, Zuständigkeit und Historie; die Eingangsschicht sorgt dafür, dass jeder Eintrag vollständig ankommt.
Ein Auswahlprozess, der in 60 Minuten funktioniert
Den Eingangssatz schreiben (10 Min.). „Eine [Rolle], die ein [Problemtyp] meldet, muss in unter [N] Klicks einreichen können, mit [diesen Artefakten]." Erfüllen zwei Anbieter das nicht, sind sie raus.
Die drei echten Warteschlangen notieren (10 Min.). Nicht hypothetisch — dort, wo Issues heute tatsächlich stauen (Kundenchat, QA-Tabelle, Kundenmail). Jede braucht einen Eingang.
Die neun Kriterien bewerten (15 Min.). 1–3 Punkte je Kriterium, Eingang und Auswertung doppelt gewichtet. Bei Gleichstand entscheidet meist Kriterium 9 (Ausstieg).
Ein echtes Issue durch zwei Finalisten schicken (15 Min.). Kein Demo-Skript — nehmt den unordentlichsten echten Bug von gestern und reicht ihn Ende-zu-Ende ein. Zeit stoppen und zählen, wie viele Rückfragen die Entwicklung hat.
Auf 12 Monate und 20 Lizenzen rechnen (10 Min.). Admin-Stunden einrechnen. Ein „kostenloses" Self-Hosted-Tool mit einer Wartungsstunde pro Woche ist nicht kostenlos.
Was es wirklich kostet
Drei Zahlen bestimmen die Rechnung, und nur die erste steht auf der Preisseite:
- Lizenzen × Monate. Achtet auf die Definition einer Lizenz. Wenn externe Melder oder Nur-Lese-Nutzer Lizenzen verbrauchen, liegt die echte Zahl weit über dem Headcount.
- Zusatzpakete für Integrationen und Automatisierung. Viele „günstige" Pläne limitieren Automationen, API-Aufrufe oder Integrationen — genau die Funktionen, die einen Tracker nützlich machen.
- Administration. Workflow-Design, Feldpflege, Duplikate zusammenführen: laufende Arbeit. Plant ein paar Stunden im Monat ein, sonst verrottet das Register.
Eine kostenlose Stufe ist für kleine Teams ein legitimer Endzustand, nicht nur eine Testphase. Wenn ihr zu ein bis fünf Personen an wenigen Webprojekten Defekte verfolgt, kann ein leichtes Erfassungstool plus ein Chat-Kanal einen Tracker vollständig ersetzen — und ihr werdet es tatsächlich aktuell halten, was die einzige Kennzahl ist, die zählt.
Migrations-Checkliste
Ein Wechsel zwischen Trackern ist vor allem ein Anhangs- und Kommentarproblem, kein Feldproblem.
- Alles exportieren: Issues, Kommentare, Anhänge, Beobachter, Statushistorie.
- Status auf die Zielzustände abbilden, nicht eins zu eins — ihr braucht fast immer weniger Zustände als jetzt.
- Vor dem Umzug entscheiden, was mit geschlossenen Issues älter als 12 Monate passiert.
- Das alte System mindestens ein Quartal lesbar halten; irgendwer braucht einen Link.
- Erst Integrationen umstellen, dann Nutzer einladen — die umgekehrte Reihenfolge erzeugt eine Woche doppelter Benachrichtigungen.
- Nur für P0/P1 eine Woche doppelt erfassen, dann umschalten.
- Nach dem Umschalten den Eingang prüfen: Der schnellste Weg, eine Migration zu töten, ist ein kaputter Melde-Button.
FAQ
Ist Jira ein Issue-Tracking-System?
Ja. Jira ist ein konfigurierbarer Issue Tracker, der zusätzlich Projekt- und Sprintplanung abdeckt. Eine starke Wahl, wenn Workflow-Flexibilität zählt und jemand die Konfiguration verantwortet.
Was ist der Unterschied zwischen Issue Tracking und Bug Tracking?
Bug Tracking umfasst nur Defekte. Issue Tracking umfasst alles, was eine Entscheidung braucht — Defekte, Aufgaben, Anfragen, Fragen — mit Defekten als einem Issue-Typ. Die meisten Bug-Tracker wachsen zum Issue-Tracking-System.
Brauchen kleine Teams ein Issue-Tracking-System?
Ein bis fünf Personen kommen mit einem Chat-Kanal, einem Erfassungstool und einer gemeinsamen Liste aus, solange jeder Eintrag einen Verantwortlichen und einen Status hat. Sobald zwei Personen nicht sagen können, was schon behoben wird, rechnet sich ein Tracker.
Reicht nicht eine Tabelle?
Für ein kleines, kurzes Projekt ist eine Tabelle ein legitimes Register. Sie bricht, sobald Berechtigungen, Benachrichtigungen, Anhänge und eine Historie der Statusänderungen gebraucht werden — meist, wenn der erste externe Kunde dazukommt.
Was ist das günstigste sinnvolle Setup?
Erfassen mit einem kostenlosen oder günstigen Tool, das Console-, Netzwerk- und Umgebungskontext mitliefert, und Berichte in den Chat-Kanal oder den bereits bezahlten Tracker pushen. Die Kosten liegen nahe null, die Datenqualität ist besser als bei einer vollen Suite, die per Copy-and-paste gefüttert wird.
Wie verhindern wir, dass Issues als Chat-Nachrichten ankommen?
Macht das Einreichen schneller als das Tippen einer Nachricht: ein Klick, ein annotierter Screenshot, automatische Umgebung — und ein Ziel, das das Team ohnehin liest. Wenn Melden länger dauert als Beschweren, beschweren sich die Leute.