Anhänge an Fehlerberichten: Belege direkt beim Bug aufbewahren

workflow

Jedes Team kennt eine Version dieser Geschichte. Jemand meldet, dass das Rechnungs-PDF mit dem falschen Logo gerendert wird. Das Design-Team legt das richtige Asset in Slack ab. Die QA nimmt eine Bildschirmaufnahme auf und legt sie aufs gemeinsame Laufwerk. Die Kundschaft schickt die Markenrichtlinien per E-Mail. Drei Wochen später taucht das Ticket wieder auf, und die vier Dateien, die es erklären, liegen an vier Orten. Zwei davon sind inzwischen abgelaufen.

Der Fehlerbericht liegt im Tracker. Die Belege liegen überall sonst.

Warum Anhänge verstreut landen

Dass Dateien außerhalb des Bugs landen, hat Gründe, die im jeweiligen Moment alle Sinn ergeben.

Die Datei kommt vor dem Bug. Das Design-Team schickt die Spezifikation, während das Problem noch ein Gespräch in einem Channel ist. Es gibt noch kein Ticket, an das man sie hängen könnte, also bleibt sie, wo sie gelandet ist.

Das Tool macht es umständlich. Wenn Anhängen heißt, aus einer App herunterzuladen und in eine andere hochzuladen, fügen Leute stattdessen einen Link ein. Links auf Chatverläufe veralten schneller als alles andere in einem Workflow.

Der Chat fühlt sich wie der schnellste Weg an. Ist er auch, für die Person, die die Datei schickt. Die Kosten trägt, wer den Bug nächsten Monat übernimmt.

Niemand hat je festgelegt, wohin Dateien gehören. Ohne Regel wendet jede Person ihre eigene an, und jede davon ist für sich genommen vernünftig.

Was die Verstreuung kostet

Der offensichtliche Schaden ist Zeitverlust. Jemand fragt noch einmal nach einer Datei, die längst existiert, und wartet.

Der zweite Schaden ist schlimmer: Ein Fix wird nach der falschen Vorlage gebaut, weil die richtige in einem Thread lag, den niemand gefunden hat. Der Code stimmt, und das Ergebnis ist trotzdem falsch.

Der dritte Schaden bleibt unbemerkt. Ein Bug, der sich schwer rekonstruieren lässt, wird verschoben statt behoben und taucht später mit noch weniger Kontext wieder auf als beim ersten Mal.

Was an einen Bug gehört

Nicht alles. Eine Aufgabe mit zwanzig Anhängen ist ungefähr so nützlich wie eine ohne. Der Test: Beantwortet die Datei eine Frage, die die nächste Person tatsächlich haben wird?

  • Die Vorlage. Das Design, das Mockup, der Absatz der Spezifikation, der sagt, welches Verhalten richtig ist. Die meisten Meinungsverschiedenheiten über einen Bug sind in Wahrheit Meinungsverschiedenheiten über die Absicht.

  • Belege, an die die automatische Erfassung nicht herankam. Ein Foto eines Handy-Bildschirms, ein Video einer Interaktion mit Hardware, das PDF, das deine App erzeugt hat.

  • Daten, die ihn reproduzieren. Die CSV, an der der Import scheitert, die Konfiguration, die den Absturz auslöst, vorher bereinigt.

  • Kontext vom Server. Das Anwendungslog aus derselben Minute wie der Bericht, wenn die Browserseite allein nicht erklärt, was passiert ist.

Was nicht dazugehört

  • Secrets. Tokens, Zugangsdaten, echte Kundendaten. Ein Anhang ist genauso sichtbar wie die Aufgabe, an der er hängt, und Aufgaben werden geteilt.

  • Alles, was sich mühelos neu erzeugen lässt. Ein Screenshot einer Seite, die alle in fünf Sekunden öffnen können, ist Rauschen in der Liste.

  • Ganze Archive. Ein 200-MB-Ordner, „für alle Fälle“ angehängt, ist eine Datei, die nie jemand öffnen wird. Zieh den Teil heraus, auf den es ankommt, und häng den an.

Vier Gewohnheiten, mit denen es funktioniert

Häng an, wenn du fragst. Wenn du jemanden aus dem Team um die Spezifikation bittest, bitte darum, sie an die Aufgabe zu hängen, statt sie dir zu schicken. Ein Satz mehr, und die Datei liegt dort, wo die nächste Person sucht.

Benenn Dateien so, dass sich die Liste wie Antworten liest. correct-invoice-logo.svg schlägt Screenshot 2026-03-04 at 14.22.11.png. Man sollte die Liste der Anhänge überfliegen können, ohne etwas zu öffnen.

Sag, warum die Datei da ist. Eine Zeile in der Beschreibung, die auf den Anhang verweist, macht aus einem Haufen Dateien ein Argument. „Der Header sollte dem zweiten Frame in der Designdatei entsprechen“ ist weit mehr wert als die Designdatei allein.

Entfern Dateien, die nicht mehr stimmen. Ein überholtes Mockup, das angehängt bleibt, wird irgendwann jemand benutzen. Es zu löschen gehört dazu, den Fix abzuschließen.

So funktioniert das in BugDump

Berichte kommen mit ihren Belegen schon im Anhang: Console-Logs, Netzwerkanfragen, ein Session-Replay, ein Screenshot, die Umgebung, in der der Bug gemeldet wurde. Das deckt ab, was im Browser passiert ist. Es deckt nicht ab, was hätte passieren sollen, und diese Hälfte liefern deine eigenen Dateien.

Jede Aufgabe hat unter der Beschreibung einen Abschnitt „Anhänge“. Du hängst Dateien beim Erstellen der Aufgabe an, fügst später weitere über die Aufgabenseite oder das Seitenpanel des Boards hinzu oder ziehst eine Datei vom Desktop und lässt sie irgendwo auf dem Aufgabenbildschirm fallen.

Dateien, die in der Beschreibung stecken (ein eingefügtes Bild, ein Dokument-Chip im Text), stehen ebenfalls dort, separat gruppiert. Die entfernst du nämlich, indem du den Text bearbeitest, zu dem sie gehören, und nicht über die Liste.

Ein kleinerer Vorteil hat sich als wichtiger herausgestellt, als ich erwartet hatte. Wenn ein KI-Agent einen Bug über den MCP-Server liest, sieht er jetzt neben den Berichten auch die Anhänge der Aufgabe. Ein Agent, der die angehängte Spezifikation lesen kann, argumentiert mit denselben Belegen wie du.

Die Regel hinter allem

Leg die Datei dorthin, wo die Frage gestellt wird.

„Wie sollte das eigentlich aussehen?“ wird am Bug gefragt: Monate nachdem das Design verschickt wurde, von einer Person, die beim ursprünglichen Gespräch nicht dabei war, genau in dem Moment, in dem sie entscheidet, was gebaut wird. Nur dort nützt die Antwort etwas.

Mehr zum Thema