QREATA / Anwendungsfälle

Screen Recorder für Bug-Reports: was Sie aufnehmen und in welcher Reihenfolge

Ein Bug-Video hilft, wenn es drei Dinge nacheinander zeigt: den Ausgangszustand, die genaue Aktion und das falsche Ergebnis. Hier finden Sie eine Aufnahmereihenfolge für 60 Sekunden, eine Ticket-Vorlage, die Sie neben das Video kopieren, ein ausgefülltes Beispiel und die Mac-Einrichtung, mit der der App-Ton mit aufgenommen wird, wenn der Fehler hörbar ist.

Qreata für Mac testen Passt es zu Ihnen? ↓

7 Tage testen · 49 $ einmalig · kein Abo · Apple Silicon · macOS 14+ · App-Oberfläche auf Englisch

Die kurze Antwort

Ein gutes Bug-Report-Video dauert 30 bis 90 Sekunden und zeigt den Ausgangszustand, die genauen Schritte und das falsche Ergebnis; der Fehler bleibt dabei etwa drei Sekunden im Bild stehen. Hängen Sie es an ein schriftliches Ticket mit Build, Betriebssystemversion, nummerierten Schritten sowie erwartetem und tatsächlichem Verhalten. Achten Sie am Mac darauf, dass das Systemaudio in der Aufnahme ist, wenn der Fehler mit Ton zu tun hat, und exportieren Sie eine MP4-Datei, damit sie direkt im Ticketsystem abgespielt wird.

Nehmen Sie ein Video auf, wenn …

Der Fehler steckt in Bewegung, Timing oder Abfolge, und ein Standbild kann ihn nicht zeigen.

Es geht um ein Flackern, eine hängende Animation, einen Layoutsprung oder eine Race Condition zwischen zwei Klicks.
Der Weg dorthin hat mehr als fünf Schritte, und immer wieder wird einer übersehen.
Der Fehler tritt sporadisch auf, und Sie brauchen einen Beleg für das eine Mal, als er passiert ist.
Er ist hörbar: Knistern, ein Ton, der zweimal abgespielt wird, Audio, das aus dem Takt läuft.

Schreiben Sie es auf oder machen Sie einen Screenshot, wenn …

Der Beleg ist statisch oder besteht aus Text. In einem Video müsste der Entwickler erst danach suchen.

Es ist ein Tippfehler, eine falsche Farbe oder ein verrutschtes Label. Ein Screenshot mit Anmerkungen genügt.
Der Beleg ist ein Stacktrace, ein fehlgeschlagener Request oder eine Logzeile. Fügen Sie ihn als Text ein, damit er durchsuchbar ist.
Der Fehler lässt sich in einem Schritt reproduzieren und tritt jedes Mal auf.
Auf dem Bildschirm sind echte Kundendaten zu sehen, Sie können nicht auf ein Demo-Konto wechseln, und Sie haben keine Möglichkeit, sie weichzuzeichnen.

Bug-Report-Video aufnehmen: die Reihenfolge für 60 Sekunden

Reproduzieren Sie den Fehler einmal ohne Aufnahme, damit Sie den Weg kennen. Wechseln Sie dann auf ein Demo-Konto, schließen Sie Chat und Mail, damit keine Benachrichtigung ins Bild rutscht, und nehmen Sie in dieser Reihenfolge einen durchgehenden Take auf.

0:00–0:05 · Kontext. Sagen Sie Build und Umgebung laut an: „Build 4.12.0, Staging, Admin-Konto.“
0:05–0:15 · Ausgangszustand. Zeigen Sie den Bildschirm, bevor etwas schiefgeht, samt URL oder Fenstertitel.
0:15–0:40 · Schritte. Führen Sie jede Aktion in normalem Tempo aus und benennen Sie sie dabei: „Ich gebe einen Namen ein, ich wähle eine Rolle, ich klicke auf Speichern.“
0:40–0:50 · Fehler. Bewegen Sie den Mauszeiger nicht mehr und lassen Sie das falsche Ergebnis drei Sekunden im Bild stehen.
0:50–1:00 · Erwartung. Sagen Sie in einem Satz, was hätte passieren sollen. Lässt sich der Fehler jedes Mal reproduzieren, lösen Sie ihn ein zweites Mal aus.

Bug-Report-Vorlage zum Kopieren neben das Video

Das Video ist der Beleg. Der Tickettext ist das, was gesucht, priorisiert und vom Fix aus verlinkt wird. Kopieren Sie diese Felder ins Ticket und füllen Sie jede Zeile aus.

Titel: [Ansicht oder Funktion] + [Aktion] + [falsches Ergebnis]. Beispiel: „Einladungsformular: Speichern leert alle Felder bei Rolle Betrachter.“
Umgebung: App-Build, Betriebssystemversion, Browser und Version, Kontotyp oder Rolle.
Ausgangszustand: was vor Schritt 1 gelten muss (angemeldet als …, Feature-Flag …, Beispieldatensatz …).
Schritte zur Reproduktion: nummeriert, eine Aktion pro Zeile.
Erwartetes Ergebnis: ein Satz.
Tatsächliches Ergebnis: ein Satz, dazu der genaue Fehlertext, falls es einen gibt.
Häufigkeit: jedes Mal oder N von 10 Versuchen.
Video: Datei oder Link, mit dem Zeitstempel des Fehlers (zum Beispiel 0:42).
Logs: Konsolenausgabe oder Request-ID, als Text eingefügt.

Beispiel: ein Formular, das sich beim Speichern selbst leert

Die Situation: Im Staging-Build einer Teamverwaltungs-App löscht das Speichern einer Einladung mit der Rolle Betrachter das Formular und verschickt nichts. Mit der Rolle Bearbeiter funktioniert es. Das Video ist 48 Sekunden lang, der Fehler ist bei 0:31 zu sehen. Der Tickettext lautet:

Titel: Einladungsformular: Speichern leert alle Felder bei Rolle Betrachter.
Umgebung: Build 4.12.0 (Staging), macOS 15.1, Chrome 129, Workspace-Admin.
Ausgangszustand: angemeldet als [email protected], Team → Mitglieder geöffnet, keine ausstehenden Einladungen.
Schritte: 1. Auf Mitglied einladen klicken. 2. Name „Jan Peters“ und E-Mail [email protected] eingeben. 3. Rolle auf Betrachter setzen. 4. Auf Speichern klicken.
Erwartet: Die Einladung erscheint unter Ausstehend mit der Rolle Betrachter.
Tatsächlich: Das Formular wird geleert, es erscheint kein Hinweis, und Ausstehend bleibt bei 0. Kein Fehler auf dem Bildschirm.
Häufigkeit: 5 von 5 mit Betrachter, 0 von 5 mit Bearbeiter.
Video: invite-viewer-bug.mp4, Fehler bei 0:31. Zweite Reproduktion bei 0:40.
Logs: POST /invites liefert 422, „role: unsupported value“.

Video, Screenshot oder schriftliche Schritte: was ins Ticket gehört

Wählen Sie das Format danach, was der Entwickler sehen muss. Die meisten guten Reports kombinieren zwei: schriftliche Schritte plus entweder ein Video oder einen Screenshot.

Welches Belegformat zu welcher Art von Fehler passt
Fehlertyp	Bester Beleg	Warum
Falscher Text, falsche Farbe oder Ausrichtung	Screenshot mit Anmerkungen	Das Problem ist in einem Bild sichtbar
Flackern, Animation oder Timing	Video, 30–60 Sekunden	Nur Bewegung zeigt es
Langer Weg (6+ Schritte)	Video plus nummerierte Schritte	Das Video belegt den Weg, der Text macht ihn durchsuchbar
Sporadischer Fehler	Video des einen Auftretens	Er lässt sich womöglich nicht auf Abruf reproduzieren
Tonproblem	Video mit Systemaudio	Der Entwickler muss es hören
Absturz oder API-Fehler	Logtext plus Schritte	Der Stacktrace zählt mehr als Pixel

Audio-Bugs und seltene Fehler am Mac mit Qreata aufnehmen

Bei Audio-Bugs lässt Sie ein Allzweck-Recorder im Stich. Angenommen, Ihre App spielt ihren Benachrichtigungston zweimal ab. Qreata nimmt das Systemaudio immer zusammen mit dem Bildschirm auf, auf einer eigenen Spur neben der Mikrofonspur. Es gibt also nichts einzuschalten und nichts zu vergessen. Vor dem Export können Sie die Mikrofonspur stummschalten oder leiser stellen, sodass der Entwickler den doppelten Ton hört, ohne Ihre Tastatur und Ihre Stimme darüber.

Bei einem Fehler, der einmal am Tag auftritt, ist die Sorge, den Take zu verlieren. Qreata schreibt die Aufnahme in Fünf-Sekunden-Blöcken mit einem Wiederherstellungsjournal auf die Festplatte. Wird die Sitzung unterbrochen, ist der bereits gespeicherte Teil beim nächsten Öffnen der App wieder da. Vor dem Start zeigt der „Active source check“ Livebild und Ton für jede Quelle.

Steckt der Fehler in einem kleinen Fenster, wählen Sie als Aufnahmeziel „Window“ und nicht „Display“, damit der Text im Player des Ticketsystems lesbar bleibt. Nach der Aufnahme können Sie den Mauszeiger vergrößern und Klicks hervorheben. So sieht der Entwickler genau, wohin Sie geklickt haben.

Den Fehler selbst lassen Sie unangetastet. Haben Sie in den ersten fünf Sekunden den Build falsch genannt, ziehen Sie mit Replace Take (im Editor das Werkzeug „Rerecord“) bei gedrückter Umschalttaste über 0:00–0:06 in der Timeline und nehmen nur diesen Satz neu auf, über die vollen sechs Sekunden. Das Material mit dem Fehler bei 0:31 bleibt genau so, wie es aufgenommen wurde.

Die Aufnahme bleibt auf Ihrem Mac, solange Sie nicht auf eine Upload-Schaltfläche klicken, und zum Aufnehmen brauchen Sie kein Konto. Ein Demo-Konto bleibt die erste Wahl, aber manche Fehler lassen sich nur in einem echten Konto reproduzieren. Schalten Sie dann vor der Aufnahme „Blur · select elements“ ein und klicken Sie die Elemente an, die verborgen werden sollen, bis zu 8, etwa eine E-Mail-Spalte: Die Weichzeichnung folgt ihnen, wenn die Seite scrollt. Dafür ist die macOS-Berechtigung „Bedienungshilfen“ nötig, und die Weichzeichnung bleibt dauerhaft in der Aufnahme. Für etwas, das Ihnen erst später auffällt, deckt das Werkzeug „Blur“ im Editor ein feststehendes Rechteck für einen Zeitabschnitt ab. Zum Ausprobieren nehmen Sie in der 7-tägigen Testversion einen Fehler, den Sie bereits gemeldet haben: Nehmen Sie ihn in der Reihenfolge oben auf und vergleichen Sie das Ergebnis mit Ihrem ursprünglichen Report. Das dauert etwa zehn Minuten.

Häufige Fehler, wegen derer ein Bug-Video zurückkommt

Aus diesen Gründen antwortet ein Entwickler auf einen Report mit angehängtem Video mit „nicht reproduzierbar“.

Mittendrin anfangen. Das Video beginnt mit dem Fehler, und niemand erkennt, wie Sie dorthin gekommen sind.
Die Schritte wegschneiden. Wer die „langweiligen“ 20 Sekunden vor dem Fehler wegschneidet, entfernt die Reproduktion.
Keine Build-Nummer. Der Fehler ist in einem neueren Build vielleicht schon behoben.
Eine Fünf-Minuten-Aufnahme mit dem Fehler bei 4:10 und ohne Zeitstempel im Ticket.
Einen sporadischen Fehler nachstellen und die Nachstellung als das ursprüngliche Ereignis einreichen.
Das gesamte 4K-Display aufnehmen, obwohl der Fehler in einem kleinen Fenster steckt, sodass der Text im Player des Ticketsystems unlesbar ist.
Ein Video ohne schriftliche Schritte. Später kann niemand danach suchen.

Fragen, die sich lohnen

Wie lang sollte ein Bug-Report-Video sein?

30 bis 90 Sekunden. Das reicht für den Ausgangszustand, die Schritte und den Fehler, der drei Sekunden stehen bleibt. Ist der Weg länger, behalten Sie den vollständigen Take und schreiben den Zeitstempel des Fehlers ins Ticket.

Sollte ich ein Bug-Report-Video kommentieren?

Ja, kurz. Nennen Sie den Build, benennen Sie jede Aktion, während Sie sie ausführen, und sagen Sie am Ende, was Sie erwartet hätten. Verzichten Sie nur dann auf den Kommentar, wenn es um einen Tonfehler geht und Ihre Stimme ihn überdecken würde.

Welches Dateiformat sollte ein Bug-Report-Video haben?

MP4 mit H.264-Video. Es läuft in jedem aktuellen Browser, der Entwickler kann es also direkt im Ticket ansehen, ohne es herunterzuladen. 1080p reicht für lesbaren UI-Text und hält die Datei klein.

Wie verberge ich sensible Daten in einer Bug-Aufnahme?

Nutzen Sie zuerst ein Demo-Konto und Beispieldatensätze. Braucht der Fehler echte Daten, zeichnet „Blur · select elements“ in Qreata während der Aufnahme die Elemente der Oberfläche weich, die Sie auswählen, und folgt ihnen, wenn die Seite scrollt; das Werkzeug „Blur“ im Editor deckt nachträglich ein feststehendes Rechteck ab. Automatisch erkannt wird nichts, sehen Sie sich die Aufnahme also an, bevor Sie sie anhängen.

Kann ich am Mac einen Fehler mit dem Ton der App aufnehmen?

Ja. Qreata nimmt das Systemaudio immer mit dem Bildschirm auf, auf einer vom Mikrofon getrennten Spur. Sie können also Ihre Stimme stummschalten und den Ton der App im Export behalten.

Hängt Qreata Videos an Jira, Linear oder GitHub an?

Nein. Qreata hat keine Integrationen für Ticketsysteme. Exportieren Sie die MP4-Datei und ziehen Sie sie ins Ticket, oder fügen Sie einen Link ein, wenn Sie sie zu Google Drive oder in die Qreata Cloud hochladen.