Blog › Tutorials

Reproduktionsschritte schreiben: 5 Beispiele (2026)

🔧 Tutorials · 8 Min. Lesezeit · 9. Oktober 2026
Warum „kann ich nicht reproduzieren" fast immer ein Schritte-Problem ist 5 Regeln für brauchbare Schritte Wie fein sollten die Schritte sein? 5 vollständige Beispiele Beispiel 1: Login und Authentifizierung (5 Schritte) Beispiel 2: Zahlung und Gutscheine (6 Schritte) Beispiel 3: Mobile Touch (5 Schritte) Beispiel 4: API und Daten (4 Schritte) Beispiel 5: Sporadischer Bug (mit Wahrscheinlichkeit und Timing) 7 Fehler, die deine Schritte ungültig machen Checkliste vor dem Absenden FAQ Die Schritte schreibst du selbst; die Nachweise können automatisch entstehen Weiterlesen

Warum „kann ich nicht reproduzieren" fast immer ein Schritte-Problem ist

Gute Reproduktionsschritte = ein klarer Startpunkt + eine Aktion pro Schritt + echte Daten + die Beobachtung bei jedem Schritt. Kann jemand sie laut vorlesen und landet auf demselben Bildschirm, sind die Schritte gut genug. Unten findest du 5 Regeln, einen Test für den richtigen Detaillierungsgrad, 5 vollständige Beispiele (inklusive der Frage, wie man einen sporadischen Bug beschreibt) und eine Checkliste für das Absenden.

Wenn ein Entwickler mit „kann ich nicht reproduzieren" antwortet, ist das selten Unwille. In den Schritten fehlt etwas — und zwar meist eines von drei Dingen:

  • Der Startpunkt fehlt: keine Vorbedingungen dokumentiert. Du warst als Enterprise-Konto angemeldet, der Entwickler nutzte ein privates — zwei verschiedene Codepfade.
  • Aktionen wurden zusammengezogen: Ein Schritt sagt „Formular ausfüllen und absenden", aber der Fehler steckt in der automatischen Speicherung zwischen Ausfüllen und Absenden.
  • Daten fehlen: Platzhalter statt echter Werte — und der Bug tritt nur auf, wenn die E-Mail-Adresse ein + enthält.

    • In einem Satz: Schritte sind kein Protokoll für dich, sondern eine Route für andere.

    5 Regeln für brauchbare Schritte

  • Startpunkt klar benennen: Login-Status, Datenzustand und Einstiegs-URL gehören in die Vorbedingungen, nicht in Schritt 1 gequetscht.
  • Eine Aktion pro Schritt: Jede Nummer macht genau eine Sache, damit Leser sie abhaken können.
  • Echte Daten verwenden: schreib user+test@x.com, nicht „eine E-Mail-Adresse".
  • Beobachtungen notieren (empfohlen): Nach Schlüsselschritten ergänze „hier zeigt die Seite X", damit der Entwickler sieht, wo es abweicht.
  • Umgebung ins Umgebungsfeld oder in die erste Zeile: Browser, OS, Gerät, Viewport-Breite — fehlt eines, kann die Reproduktion scheitern.

    • Wie fein sollten die Schritte sein?

    Detaillierung Beispiel Problem
    Zu grob „Checkout öffnen, Artikel entfernen, Zähler ist falsch" Drei Aktionen in einem Satz — niemand erkennt, wo es bricht
    Genau richtig „1. /cart öffnen 2. Rechts neben dem Produkt auf Löschen klicken 3. Den Zähler oben auf der Seite beobachten" Eine Aktion pro Schritt, jeder einzeln prüfbar
    Zu fein „1. Zeiger auf die Schaltfläche bewegen 2. linke Maustaste drücken 3. loslassen" Physische Aktionen zerlegt — schwerer zu lesen, nicht leichter

    Der Test: Stelle nach dem Schreiben zwei Fragen. ① Kommt jemand anderes ohne meinen Screenshot auf denselben Bildschirm? ② Kann ein Entwickler in zwei Minuten sagen, ob es Frontend, API oder Daten betrifft? Zweimal Ja heißt: Der Detaillierungsgrad passt.

    5 vollständige Beispiele

    Beispiel 1: Login und Authentifizierung (5 Schritte)

    Vorbedingungen: Konto test@example.com registriert und aktiv. Umgebung: Chrome 120 / macOS 14 / Desktop / 1920×1080 / Inkognito-Fenster.

  • https://app.example.com/login öffnen
  • E-Mail test@example.com und das korrekte Passwort eingeben
  • Dreimal in Folge ein falsches Bild-Captcha eingeben
  • Beim vierten Versuch ein gültiges Captcha eingeben und auf „Anmelden" klicken
  • Die angezeigte Meldung beobachten

    • Erwartet: Meldung „Captcha falsch, bitte erneut versuchen", Konto bleibt entsperrt. Tatsächlich: Meldung „Konto gesperrt, in 24 Stunden erneut versuchen" — obwohl das Captcha korrekt war.

    Beispiel 2: Zahlung und Gutscheine (6 Schritte)

    Vorbedingungen: 2 Artikel im Warenkorb, Summe 1.299 €; Konto ist ein Enterprise-Konto. Umgebung: Chrome 120 / Windows 11 / Desktop / 1440×900 / Enterprise-Konto.

  • /cart öffnen und die Summe 1.299 € bestätigen
  • Auf „Zur Kasse" klicken
  • Im Gutscheinfeld den Code SAVE100 eingeben (seit drei Tagen abgelaufen)
  • Auf „Anwenden" klicken
  • Den Hinweis oben auf der Seite und den Zustand des Warenkorbs beobachten
  • Seite neu laden und erneut beobachten

    • Erwartet: Hinweis „Gutschein abgelaufen", Warenkorb unverändert. Tatsächlich: Meldung „Gutschein angewendet" und 100 € werden abgezogen; im Moment des Klicks auf „Anwenden" verschwinden beide Artikel aus dem Warenkorb.

    Beispiel 3: Mobile Touch (5 Schritte)

    Vorbedingungen: angemeldet, 1 Artikel im Warenkorb. Umgebung: iPhone 14 / iOS 17.2 / Safari / Viewport 390×844.

  • https://shop.example.com/cart öffnen
  • Zum Adressformular am Seitenende scrollen
  • Das Feld „Name des Empfängers" antippen, um die Tastatur zu öffnen
  • Den Button „Bestellung absenden" über der Tastatur ansehen
  • Diesen Button antippen

    • Erwartet: Der Button wandert über die Tastatur und bleibt antippbar. Tatsächlich: Die Tastatur verdeckt rund 60 % des Buttons, Taps in diesem Bereich bewirken nichts.

    Beispiel 4: API und Daten (4 Schritte)

    Vorbedingungen: Token für die Testumgebung vorhanden; in der Datenbank liegen 12.400 Bestellungen, 12 davon passen zum Suchbegriff. Umgebung: https://api-test.example.com / curl 8.x.

  • GET /api/orders/export?month=2026-08 mit dem Header Authorization: Bearer <token>
  • Auf die Antwort warten
  • HTTP-Statuscode und Response-Body beobachten
  • Erneut mit month=2026-08-01~2026-08-07 versuchen

    • Erwartet: 200 mit einer Export-Job-ID oder 202, wenn der Job eingereiht wurde. Tatsächlich: 504 (Gateway-Timeout); mit kleinerem Zeitraum kommt 200 — der Schwellenwert hängt also an der Datenmenge.

    Beispiel 5: Sporadischer Bug (mit Wahrscheinlichkeit und Timing)

    Vorbedingungen: Konto ohne Guthaben; die Testkarte ist beim Testnutzer hinterlegt. Umgebung: Chrome 120 / macOS 14 / Netzwerk auf 3G gedrosselt.

  • /checkout öffnen und die Zahlungsdaten ausfüllen
  • DevTools öffnen und das Network-Panel auf 3G-Drosselung stellen
  • Schnell doppelt auf „Zahlung bestätigen" klicken (Klickabstand ca. 300ms)
  • Bestellliste und Zahlungsjournal beobachten

    • Erwartet: Genau eine Bestellung; Doppelklicks werden clientseitig entdoppelt oder serverseitig durch Idempotenz blockiert. Tatsächlich: In 3 von 10 Versuchen entstanden zwei Bestellungen (Reproduktionsbedingungen: Abstand <500ms und Netzwerklatenz >1s). Aufnahme des Network-Panels und die Request-IDs beider POST /api/orders-Aufrufe sind angehängt.

    So beschreibst du einen sporadischen Bug:

    • Gib eine Wahrscheinlichkeit an, nicht das Wort „sporadisch": „3 von 10 Versuchen" ist hundertmal nützlicher.
    • Gib Timing oder Schwellenwert an: „Abstand <500ms", „Netzwerklatenz >1s" — solche Bedingungen sind oft der Hinweis auf die Ursache.
    • Gib die Beweisart an: Bildschirmaufnahme und Konsolen-Logs sind die einzigen dauerhaften Nachweise, die ein sporadischer Bug mitbringen kann.

    7 Fehler, die deine Schritte ungültig machen

  • Mit „Homepage öffnen" beginnen: Navigation ist Füllmaterial, die ersten fünf Schritte sind Rauschen.
  • Mehrere Aktionen in einem Schritt: „Formular ausfüllen und absenden" — der Fehler lässt sich nicht verorten.
  • Platzhalterbeschreibungen: „korrekten Benutzernamen und Passwort eingeben", obwohl genau diese Werte die entscheidende Variable sind.
  • Fehlende Daten-Vorbedingungen: wie viele Artikel im Warenkorb, welcher Kontotyp, ob schon erstattet wurde.
  • Interne Fachsprache: „den alten Flow durchlaufen", „Plan-B-Konto nutzen" — externe Mitwirkende können das nicht entschlüsseln.
  • Erwartete Ergebnisse in die Schritte geschmuggelt: „in Schritt 3 sollte ein Dialog erscheinen" — das gehört in ein eigenes Feld.
  • Spekulation in den Schritten: „Schritt 4 bricht ab, weil der Cache veraltet ist" — Vermutungen gehören in die Notizen, markiert als „vermutet".

    • Checkliste vor dem Absenden

    • Vorbedingungen notiert (Login-Status + Datenzustand)?
    • Der erste Schritt ist eine fachliche Aktion, nicht „Browser öffnen"?
    • Genau eine Aktion pro Nummer?
    • Echte Werte statt Platzhalter?
    • Beobachtungen nach den Schlüsselschritten notiert?
    • Erwartetes und tatsächliches Ergebnis getrennt?
    • Bei sporadischen Bugs Wahrscheinlichkeit und Timing angegeben?

    FAQ

    Wie viele Schritte sollte eine Reproduktion haben?

    Üblicherweise 3–8. Weniger als 3 bedeutet meist fehlende Vorbedingungen; mehr als 8 lässt sich meist kürzen — die Navigation in die Vorbedingungen verschieben und nur die auslösenden Aktionen behalten.

    Gehört die Umgebung in die Schritte oder in ein eigenes Feld?

    In ein eigenes Feld. In den Schritten stört sie den Lesefluss und ist nicht filterbar. Hat das Format kein Umgebungsfeld (etwa eine E-Mail), dann deklariere sie in einer Zeile über den Schritten: „Umgebung: Chrome 120 / macOS 14 / 1920×1080".

    Sollen belanglose Aktionen wie „Zurück klicken" oder „Dialog schließen" mit rein?

    Nur wenn sie Teil der Reproduktionsbedingungen sind. Der Test: Streiche den Schritt — tritt der Fehler noch auf? Wenn ja, weg damit; wenn nein, muss er bleiben.

    Wie schreibe ich Schritte für einen Bug, den ich selbst nicht reproduzieren kann?

    Schreibe drei Dinge ehrlich auf: ① die probierten Bedingungen (welche Versuche klappten, welche nicht); ② den stärksten vorhandenen Nachweis (Aufnahme, Konsolen-Logs, Netzwerkanfragen); ③ beobachtete Korrelationen („nur bei langsamem Netz"). Markiere es im Titel oder in den Notizen als „Reproduktionsbedingungen unklar", statt es als reproduzierbar darzustellen.

    Worin unterscheiden sich Reproduktionsschritte von Testfällen?

    Ein Testfall ist eine vorab entworfene Prüfliste — er deckt Normalfälle, Grenzen und Ausnahmen ab und zielt auf Abdeckung. Reproduktionsschritte sind ein nachträglich protokollierter Pfad, der nur das Problem zuverlässig wiederholen soll. Beides befruchtet sich, aber die Ziele unterscheiden sich — zum Schreiben von Testfällen siehe Testfall-Vorlage mit Beispielen.

    Die Schritte schreibst du selbst; die Nachweise können automatisch entstehen

    Die Schritte muss die Person schreiben, die geklickt hat — nur du weißt, was du getan hast. Umgebung und Nachweise, die mitgeschickt werden, können sich aber selbst füllen:

    • Bildschirmaufnahme: aktuellen Tab per Klick aufnehmen und kürzen, damit auch sporadische Bugs einen abspielbaren Nachweis haben.
    • Diagnosedaten: Konsolen-Logs auf Fehlerlevel und fehlgeschlagene Netzwerkanfragen (HTTP ≥ 400) werden gesammelt, sensible Parameter automatisch unkenntlich gemacht.
    • Automatischer technischer Kontext: URL, Browser, Betriebssystem, Auflösung und Viewport werden für dich eingetragen.
    • Annotierte Screenshots: Bereich markieren und Pfeile, Rahmen und Text ergänzen, um den Fehler festzuhalten.
    • Teilen oder synchronisieren: einen Freigabelink ohne Registrierung erzeugen oder den Bericht in eine Feishu-Base bzw. einen generischen Webhook schicken.

    Weiterlesen

    #steps to reproduce #bug reporting #QA #tutorial
    Teilen

    Verwandte Artikel