Ein großer Teil der Bugreports, die Entwickler erhalten, besteht nur aus einem Bild und den Worten „ist kaputt“. Der Screenshot leistet die Hälfte der Arbeit; die andere Hälfte hängt davon ab, wie er aufgenommen, beschriftet und verpackt wurde. Dieser Guide ist eine praktische Vorlage, damit Screenshots ihr volles Gewicht tragen.

Was ein guter Report mit Screenshot enthält

  1. Den Zustand selbst, den eigentlichen Bildschirm mit dem Problem, nicht eine Beschreibung davon.
  2. Ein Zeiger, ein Pfeil oder Rahmen, der genau das betroffene Element markiert.
  3. Kontext-Metadaten: welche App bzw. welcher Build, welches Betriebssystem und idealerweise die Auflösung, damit der Entwickler umgebungsspezifische Darstellungsfehler ausschließen kann.
  4. Reproduktionsschritte, nummeriert, kurz, in der richtigen Reihenfolge. Der Screenshot ist Schritt N; der Leser braucht die Schritte 1 bis N-1.
  5. Erwartet vs. tatsächlich, je eine Zeile. „Erwartet: Dropdown bleibt offen. Tatsächlich: Dropdown schließt sofort.“

Alles andere ist optional. Widerstehe dem Drang, fünf Screenshots anzuhängen, wenn ein beschrifteter Screenshot plus drei Reproduktionsschritte die ganze Geschichte erzählen.

Erfassen speziell für einen Bugreport

Den richtigen Umfang erfassen

  • Bereich statt Vollbild, in den meisten Fällen. Ein enger Zuschnitt um die kaputte Komponente liest sich am Handy schneller und gibt weniger von deiner Umgebung preis.
  • Vollbild nur, wenn die Position zählt, z. B. bei einem Layoutfehler, bei dem es auf das Verhältnis zwischen den Panels ankommt.
  • Bei Fehlern in Übergängen beide Zustände erfassen. Wenn ein Klick auf X das Element Y verschwinden lässt, brauchst du den Zustand davor und danach. Zwei kleine Aufnahmen sind besser als eine mehrdeutige.

Mit Absicht beschriften

Der Beschriftungs-Guide deckt die Werkzeuge im Detail ab; für einen Report brauchst du meist:

Beschriftung Wann einsetzen
Pfeil Ein bestimmtes Element ist falsch. Die Standardwahl.
Rechteck Ein Bereich oder Container verhält sich falsch (Abstand, Überlauf, abgeschnittene Inhalte).
Text Schrittnummern bei mehrstufigen Reproduktionen; Markierungen für „erwartet“ und „tatsächlich“.
Weichzeichner Alles Sensible, das mit dem Bug nichts zu tun hat. Immer.
Zuschneiden Leerraum nach dem Beschriften entfernen, damit die Markierung das Bild trägt.

Zwei Faustregeln:

  • Ein Pfeil pro Screenshot. Wenn du drei Pfeile brauchst, brauchst du wahrscheinlich drei Screenshots.
  • Weichzeichnen vor dem Upload. Tokens, Kundennamen und interne URLs werden im Editor weichgezeichnet, bevor das Bild dein Gerät verlässt. Welches Verfahren du wählst, hängt davon ab, was lesbar bleiben muss. Nach dem Teilen gibt es kein Rückgängigmachen.

Die Metadaten einbauen, die helfen

Eine Freigabeseite, die Abmessungen, Dateigröße und Aufnahmedatum anzeigt, erspart die Rückfrage „Welche Auflösung hattest du?“. Die Freigabeseiten von Shotivo zeigen Breite × Höhe, Dateigröße, Erstellungsdatum und Ablaufzeit. Mit dem Link wird dieser Kontext also automatisch mitgeliefert.

Im Text des Reports selbst ergänzen:

  • App-Name + Version (z. B. „Shotivo 1.x“ oder die Build-Nummer des betroffenen Produkts)
  • Betriebssystem + Version („macOS 15.2“)
  • Einzeilige Anmerkung zur Umgebung, falls relevant („externes 4K-Display“, „VPN an“)

Der Workflow: drei Sekunden bis zum teilbaren Bild

Mit einer Menüleisten-Aufnahme-App (hier mit den Standardwerten von Shotivo):

  1. ⌘⇧9, über den kaputten Bereich ziehen. Der Editor öffnet sich sofort.
  2. Pfeil-Werkzeug anklicken, Element markieren; alles Sensible weichzeichnen; eng zuschneiden.
  3. ⌘↩ (Teilen), lädt hoch und kopiert einen shotivo.app/s/…-Link in deine Zwischenablage.
  4. Den Link ins Ticket einfügen, gefolgt von den Reproduktionsschritten.

Insgesamt von der ersten Taste bis zum einsatzbereiten Link: etwa drei bis fünf Sekunden. Free-Links laufen nach 7 Tagen ab; Pro-Links können bis zu 90 Tage online bleiben (standardmäßig 90 Tage). Lade das Original herunter, wenn das Ticket eine dauerhafte lokale Kopie benötigt. Wie die Aufbewahrung pro Stufe funktioniert, falls du unsicher bist, welche Grenze für dich gilt.

Vorlage

[App] [Komponente]: [einzeilige Zusammenfassung]

Schritte:
1. …
2. …
3. Beobachtung: <was passiert>

Erwartet: <was passieren sollte>

Screenshot: <Teilen-Link einfügen>
Umgebung: macOS 15.2 · App-Build 1.x · <Display-Anmerkung, falls relevant>

Fülle die Vorlage in unter einer Minute aus, und du hast einen Report, mit dem ein Entwickler arbeiten kann, ohne nachzufragen. Der Screenshot zeigt, die drei Zeilen erklären.

Häufige Fehler

  • „Siehe Anhang.“ ohne Reproduktionsschritte. Der Entwickler muss den Weg zum Zustand raten.
  • Vollbild-Aufnahme eines winzigen Problems. Der Pfeil zeigt auf 2 % des Bildes.
  • Nicht weichgezeichnete Geheimnisse. Der Report wird weitergeleitet, archiviert, indexiert. Dein Token ist jetzt öffentlich.
  • Fünf Screenshots desselben Zustands. Ein guter Screenshot plus Text ist besser als fünf mittelmäßige.
  • Screenshot nach dem „Reparieren“ gemacht. Erfasse zuerst den kaputten Zustand; später kannst du immer neu aufnehmen.

Die Messlatte liegt niedrig, und es lohnt sich, sie zu erreichen: Kann ein Entwickler, der diese App nie gesehen hat, aus deinem Text allein den kaputten Zustand erreichen und aus deinem Bild genau sehen, was falsch ist? Wenn ja, ist der Report fertig.