Sollten Sie jeden QA-Testschritt per Screenshot festhalten?

Ein QA-Protokoll hat zwei Leser: den Prüfer, der heute die Freigabe erteilt, und die Person, die eine Regression Monate später untersucht. Beide müssen sehen, was getestet wurde, mit welchen Daten und was passiert ist. Keiner von beiden braucht einen Screenshot jedes Klicks.

Dieser Beitrag beschreibt, wie Sie ein manuelles Testprotokoll gliedern und an welchen Stellen Screenshots als Nachweis dienen. Das Beispiel ist der Temposhot-Ablauf auf dem Mac.

Die Beispiele verwenden durchgängig einen Testfall: TC-142, ein Zurücksetzen des Passworts auf einer Staging-Seite. Der Test hat 4 Schritte. Ein Protokoll, das nur Prüfpunkte enthält, umfasst für ihn 5 Seiten. Die Aufnahme jedes Klicks für denselben Test ergab 11 Seiten.

Einen Testzweck festlegen

Jeder Testfall prüft genau ein Verhalten. „Nutzer kann das Passwort über einen gültigen E-Mail-Link zurücksetzen“ ist ein Testzweck. „Kontoeinstellungen funktionieren“ ist ein Testplan, kein Testfall.

Formulieren Sie den Zweck als Satz, der wahr oder falsch sein kann. Der letzte Screenshot zeigt, welches zutrifft.

Zwecke aufteilen, die zwei Tests verbergen

Ein Zweck mit „und“ verbirgt oft zwei Tests. „Nutzer kann das Passwort zurücksetzen und die E-Mail-Adresse ändern“ schlägt insgesamt fehl, wenn nur ein Teil ausfällt, und das Protokoll zeigt nicht, welcher Teil es war. Teilen Sie ihn in zwei Fälle mit eigenen IDs und eigenen Protokollen auf.

Ein eng gefasster Zweck hält das Protokoll außerdem kurz. TC-142 endet, wenn der Nutzer mit dem neuen Passwort angemeldet ist. Die Prüfung, dass das alte Passwort nicht mehr funktioniert, ist ein eigener Fall, TC-143, mit eigenem Startzustand.

Den Zweck aus Sicht des Nutzers formulieren

Ein Zweck aus Sicht des Nutzers benennt ein Ergebnis, das der Nutzer sehen kann. „Nutzer kann das Passwort über einen gültigen E-Mail-Link zurücksetzen“ endet auf einem Bildschirm: dem Dashboard nach der Anmeldung. Ein Zweck wie „Reset-Endpunkt gibt 200 zurück“ endet dagegen in einem Log. Dafür ist ein Screenshot-Protokoll das falsche Format.

Wenn ein Fall beides enthält, behalten Sie das sichtbare Ergebnis als Zweck und hängen die Log-Zeilen als Text an. Die Screenshots belegen dann das Ergebnis für den Nutzer, der Text belegt das Systemverhalten dahinter.

Voraussetzungen und Testdaten festhalten

Listen Sie alles auf, was vor Schritt 1 vorhanden sein muss, damit jede Person den Test wiederholen kann:

Punkt	Beispiel
Testfall-ID	TC-142
Build oder Version	Die getestete Build-Nummer
Umgebung	Staging-URL, macOS-Version, Browser und Version
Konto	Rolle und Name des Testkontos, niemals ein echter Kunde
Testdaten	Die Bestellung, Datei oder der Datensatz, den der Test verwendet
Vorbedingungen	Feature-Flag aktiv, Warenkorb leer, Nutzer abgemeldet

Verwenden Sie synthetische Daten. Testprotokolle werden breit geteilt und lange aufbewahrt.

Die Vorbedingungen auf der ersten Seite belegen

Eine Vorbedingung, die nur aufgeschrieben ist, lässt sich später nicht prüfen. Die erste Seite des Protokolls zeigt den Startzustand auf dem Bildschirm, etwa die abgemeldete Anmeldeseite mit sichtbarer Staging-URL. Ein Prüfer kann die Umgebung dann ohne Rückfrage bestätigen.

Ein leerer Testposteingang ist für TC-142 wichtig. Liegt eine ältere Zurücksetzungs-E-Mail im Posteingang, kann der Tester den falschen Link öffnen. Das Protokoll zeigt dann ein Bestanden für einen Link, der nicht geprüft wurde.

Testdaten verwenden, die offensichtlich fiktiv sind

Synthetische Daten sollten auf den ersten Blick als fiktiv erkennbar sein. Namen wie „QA Reset 01“ und Adressen auf einer Testdomäne zeigen jedem späteren Leser, dass keine reale Person betroffen ist. Realistisch klingende Fantasienamen, etwa ein plausibler Vor- und Nachname, werfen dagegen die Frage auf, ob das Protokoll Kundendaten enthält.

Offensichtlich fiktive Daten verringern außerdem den Aufwand für Schwärzungen. Ein Protokoll ohne personenbezogene Daten braucht kein Blur, daher reicht der kostenlose Tarif aus, und die Seiten zeigen den vollen Bildschirm ohne abgedeckte Bereiche.

Schritte mit erwarteten Prüfpunkten formulieren

Jeder Schritt erhält eine Aktion und, wo etwas Beobachtbares passieren soll, ein erwartetes Ergebnis.

1. Öffnen Sie die Anmeldeseite. Erwartet: Link Forgot password sichtbar.
2. Wählen Sie Forgot password und geben Sie die Test-E-Mail-Adresse ein. Erwartet: Bestätigungsmeldung.
3. Öffnen Sie den Reset-Link aus dem Testposteingang. Erwartet: Formular für ein neues Passwort.
4. Geben Sie ein gültiges neues Passwort ein und senden Sie es ab. Erwartet: angemeldet, Dashboard angezeigt.

Schritte ohne erwartetes Ergebnis sind Vorbereitung. Schritte mit einem erwarteten Ergebnis sind Prüfpunkte, und dort gehören die Screenshots hin.

Erwartete Ergebnisse beobachtbar machen

„Funktioniert korrekt“ ist kein erwartetes Ergebnis, weil kein Screenshot das zeigen kann. Ein erwartetes Ergebnis benennt etwas Sichtbares: einen Meldungstext, ein Feld, einen Wert oder einen Seitentitel. Die Angabe „Bestätigungsmeldung: Check your email for a reset link“ lässt sich wörtlich mit dem Bildschirm vergleichen.

Wenn ein erwartetes Ergebnis nicht auf dem Bildschirm sichtbar ist, etwa eine Zustellzeit der E-Mail, erfassen Sie es als Text in der Seitenbeschreibung. Der Screenshot zeigt dann den Bildschirm, und die Beschreibung enthält den Wert.

Schrittnummern stabil halten

Die Schrittnummern im Testfall und die Seitentitel im Protokoll müssen übereinstimmen. Wird ein Fall später bearbeitet und ein Schritt eingefügt, erhält der neue Schritt ein Suffix wie 2a, statt die Nummern neu zu vergeben. Alte Protokolle verweisen dann weiterhin auf die richtigen Schritte, und eine Regressionssuche nach „Schritt 4“ findet in jedem Build dieselbe Aktion.

Titel bearbeiten Sie im Page Inspector unter Page title. Schreiben Sie jeden Entwurfstitel so um, dass er mit Testfall- und Schritt-ID beginnt, und ergänzen Sie unter Description die Zeilen für das erwartete und das tatsächliche Ergebnis.

Vorbereitungsschritte von Prüfpunkten trennen

TC-142 enthält Vorbereitung, die das Protokoll nicht zeigt: das Öffnen des Testposteingangs, das Kopieren der E-Mail-Adresse und das Warten auf die E-Mail. Werden diese Schritte weggelassen, bleibt das Protokoll bei 5 Seiten. Schlägt eine Vorbereitungsaktion fehl, wird sie zu einem Ergebnis Blocked mit eigener Seite statt zu einer stillen Lücke.

Eine praktische Prüfung: Hat ein Schritt im Fall keine Zeile „Erwartet“, erhält er keine Seite. Hat er eine, erhält er genau eine Seite.

Sollten Sie jeden QA-Testschritt per Screenshot festhalten?

Nein. Erfassen Sie diese Momente:

• Startzustand: belegt, dass die Vorbedingungen erfüllt waren.
• Jeder Prüfpunkt: zeigt das erwartete oder unerwartete Ergebnis.
• Endergebnis: zeigt, ob der Testzweck erreicht wurde.
• Jeder Fehler: der Bildschirm im Moment der Abweichung sowie der Schritt davor.

Screenshots reiner Navigationsklicks fügen Seiten hinzu, ohne Nachweise zu liefern. Sie verlangsamen die Prüfung des Protokolls.

Mit Temposhot können Sie nur Prüfpunkte erfassen. Öffnen Sie Action Capture (Command+3), wählen Sie Configure und stellen Sie Mouse click capture so ein, dass nur Klicks mit einer Modifiziertaste oder gar keine Klicks erfasst werden. Drücken Sie dann an jedem Prüfpunkt Shift+Command+2, das Kürzel für die manuelle Erfassung. Wählen Sie Start Action Capture, dann Specific Window, führen Sie den Test aus und wählen Sie Finish capture. Das Dokument öffnet sich mit einer Seite pro Prüfpunkt.

Wenn Sie bei einem fehlschlagenden Test jeden Schritt benötigen, stellen Sie Mouse click capture wieder auf jeden Klick. Jeder erfasste Klick speichert das Fenster unmittelbar vor dem Klick. Der Leitfaden zu Action Capture listet die Erfassungsmodi auf.

Die beiden Aufnahmemodi vergleichen

Die beiden Modi beantworten unterschiedliche Fragen. Ein Protokoll mit nur Prüfpunkten beantwortet: Hat jeder Prüfpunkt das erwartete Ergebnis gezeigt? Ein Protokoll mit jedem Klick beantwortet: Was genau hat der Tester getan? Letzteres zählt vor allem bei einem Fehlschlag.

Der kostenlose Tarif begrenzt jeden Lauf von Action Capture auf 5 Schritte. Ein Protokoll mit nur Prüfpunkten für TC-142 passt genau in einen kostenlosen Lauf: den Startzustand plus 4 Prüfpunkte. Ein Lauf mit jedem Klick pausiert nach 5 Schritten und behält die bis dahin erfassten Schritte. Temposhot Pro hebt das Limit auf.

Einen Lauf nur mit Prüfpunkten konfigurieren

Configure Action Capture speichert seine Einstellungen auf dem Mac. Die Konfiguration für Prüfpunkte bleibt daher für die nächste Testsitzung erhalten. Stellen Sie sie vor der Aufnahme eines Tutorials oder Fehlerberichts zurück.

Mark clicked area gilt auch für Schritte, die mit dem manuellen Kürzel hinzugefügt werden. In einem Prüfprotokoll zeigt die Markierung auf die Stelle, an der der Zeiger zufällig stand. Das kann einen Prüfer in die Irre führen, daher bleibt sie ausgeschaltet.

TC-142 mit dem Kürzel durchführen

1. Startzustand erfassen

   Drücken Sie nach dem Countdown auf der abgemeldeten Anmeldeseite Shift+Command+2. Dies ist Seite 1.

2. Jeden Prüfpunkt erfassen

   Führen Sie jeden Schritt aus. Wenn das erwartete Ergebnis auf dem Bildschirm erscheinen soll, drücken Sie das Kürzel erneut. Die Seiten 2 bis 5 sind die 4 Prüfpunkte.

3. Abschließen

   Drücken Sie Command+. oder wählen Sie Finish capture. Das Dokument öffnet sich mit 5 Seiten.

Prüfpunkte, die schnell verschwinden

Manche erwarteten Ergebnisse sind nur wenige Sekunden sichtbar, etwa eine kurze Hinweismeldung nach dem Absenden eines Formulars. Drücken Sie das Kürzel, sobald die Meldung erscheint. Der Schritt speichert den Bildschirm in diesem Moment. Ist die Meldung vor dem Tastendruck verschwunden, wiederholen Sie den Schritt und halten die Hand auf den Tasten.

Ist ein Ergebnis zu kurz sichtbar, um es zu erfassen, schreiben Sie es in die Beschreibung und erfassen Sie den Bildschirm, der danach folgt. Zum Beispiel: „Erwartet: Hinweismeldung Password updated. Tatsächlich: Meldung gesehen, nach etwa 3 Sekunden geschlossen, Dashboard angezeigt.“ Ein Prüfer weiß dann, dass die Meldung beobachtet wurde, und warum sie nicht auf der Seite steht.

Tests über mehrere Fenster

TC-142 wechselt vom Browser zum Testposteingang und zurück. Öffnet sich der Posteingang in einem anderen Browserfenster, erfasst das Ziel Specific Window weiterhin nur das erste Fenster. Wählen Sie für einen Test mit mehreren Fenstern Full Screen und schließen Sie vor dem Durchlauf alles, was nicht zum Test gehört.

Den Modus wechseln, wenn ein Prüfpunkt fehlschlägt

Schlägt Schritt 4 fehl, zeigt ein Protokoll mit Prüfpunkten das Ergebnis, aber nicht die genaue Eingabe. Führen Sie den Test dann im Modus mit jedem Klick erneut aus, um den Weg zum Fehler festzuhalten. Hängen Sie diesen zweiten Lauf an den Fehlerbericht an und behalten Sie das erste Protokoll als Testergebnis.

Tatsächliche Ergebnisse festhalten, ohne die Historie umzuschreiben

Das Protokoll muss zeigen, was passiert ist, nicht was hätte passieren sollen. Im Dokument-Editor gilt:

• Versehen Sie jede Seite mit Schritt-ID und Aktion, etwa „TC-142 Schritt 4: Neues Passwort senden“.
• Schreiben Sie in der Page description das erwartete und das tatsächliche Ergebnis in getrennte Zeilen.
• Zeichnen Sie bei einem fehlgeschlagenen Prüfpunkt ein Rectangle (R) um den falschen Wert und fügen Sie ein Text-Label (T) mit „Fail“ hinzu.

Schneiden Sie keinen Kontext weg, den ein Prüfer braucht, etwa die URL oder das Build-Label. Verwenden Sie Framing nur, um fremde Fenster zu entfernen. Schwärzen Sie personenbezogene Daten mit Blur (B, Pro). Ändern Sie niemals einen Wert, damit ein Ergebnis richtig aussieht.

Anmerkungsregeln für Nachweise

Anmerkungen in Temposhot sind nicht destruktiv: Der Screenshot unter einem Rechteck oder Label bleibt unverändert. Das hält den Nachweis intakt. Ein Leser der exportierten PDF sieht jedoch nur die gerenderte Seite. Regeln, was eine Anmerkung darf und was nicht, halten den Export vertrauenswürdig.

Die Beschreibung in festem Format schreiben

Ein festes zweizeiliges Format macht Beschreibungen über 5 oder 50 Seiten leicht überprüfbar. Zeile eins beginnt mit „Erwartet:“ und nennt das erwartete Ergebnis. Zeile zwei beginnt mit „Tatsächlich:“ und nennt, was der Screenshot zeigt.

Für Seite 5 von TC-142 lautet die Beschreibung: „Erwartet: angemeldet, Dashboard angezeigt. Tatsächlich: Banner Reset link expired, Anmeldeformular angezeigt.“ Der Prüfer gleicht die Zeile „Tatsächlich“ mit einem Blick gegen den Screenshot ab.

Dieses QA-Ausführungsprotokoll verwenden

• Testfall-ID, Testzweck, Build, Umgebung, Tester, Datum.
• Vorbedingungen und Testdaten.
• Schritte mit erwarteten Ergebnissen.
• Screenshots von Start, Prüfpunkten, Ende und Fehlern.
• Tatsächliches Ergebnis je Prüfpunkt.
• Status: Pass, Fail oder Blocked.
• Verknüpfter Fehlerbericht für jeden Fehlschlag.

Exportieren Sie das Dokument mit Export PDF als Anhang für das Testmanagement-Tool oder als PNG-Seiten über More export formats für eingebettete Nachweise. Benennen Sie Dateien mit Testfall-ID und Build, etwa TC-142_build-2026-08-27.pdf. Der Export-Leitfaden listet die Formate auf. Um zwei Screenshots desselben Bildschirms aus verschiedenen Builds zu vergleichen, hebt das Werkzeug Compare Images Unterschiede lokal hervor.

PDF-Einstellungen für ein Testprotokoll

Die Standardeinstellungen von Export PDF passen für die meisten Protokolle: A4, Landscape, mit aktivierten Optionen Cover page, Step numbers und Page numbers, Beschreibungen vor dem Bild. Das Deckblatt beginnt mit dem Dokumenttitel und der Anzahl der Schritte. Ein Titel wie „TC-142 build 2026-08-27 Fail“ setzt das Ergebnis daher auf die erste Seite. Anpassungen der PDF-Einstellungen erfordern Temposhot Pro.

Mit Pro wechseln Teams, die auf US-Papier drucken, Paper size auf Letter. Image quality auf Small file hält ein Regressionsprotokoll mit 50 Seiten klein genug für Werkzeuge mit Anhangsgrößenlimit.

Den Status anhand der Nachweise setzen

Jeder Status braucht andere Nachweise. Ein Prüfer, der einen Status ohne passende Seiten sieht, sollte das Protokoll zurückgeben.

Protokolle nach Fall und Build ordnen

Ein Protokoll findet man später nach Testfall-ID und Build, selten nach dem Datum allein. Legen Sie pro Fall einen Ordner mit einem Unterordner pro Build an. So vergleicht eine Regressionssuche denselben Fall über alle Builds hinweg.

Dokumentbilder werden nach den Seitentiteln benannt. Titel, die mit der Schritt-ID beginnen, ergeben daher Dateinamen, die in Schrittreihenfolge sortiert werden und über Builds hinweg übereinstimmen.

Einen Prüfpunkt über Builds vergleichen

Besteht TC-142 im Build 2026-09-03, nachdem er am 2026-08-27 fehlgeschlagen ist, öffnen Sie beide PNG-Dateien von Schritt 4 in Compare Images. Die Ansicht mit Schieberegler oder Pixeldifferenz zeigt, ob sich nur das Banner geändert hat oder ob das Layout verschoben ist. Behalten Sie beide Protokolle. Das fehlgeschlagene dokumentiert die Regression.

Nachweise prüfen und freigeben

Ein Prüfer muss drei Dinge ohne Ausführung des Tests bestätigen: Die Vorbedingungen waren erfüllt, jeder Prüfpunkt zeigt das angegebene Ergebnis, und der Endstatus stimmt mit den Screenshots überein. Muss ein Prüfer raten, braucht das Protokoll einen weiteren Prüfpunkt.

Temposhot speichert Dokumente lokal und bietet keine Freigabe-Workflows. Hängen Sie die exportierten Dateien an das Testmanagement-Tool oder das Ticket an, in dem Freigaben erfasst werden.

Die Prüfung des Prüfers in fester Reihenfolge

Ein Prüfer kann ein Protokoll mit 5 Seiten in wenigen Minuten prüfen, wenn er es in fester Reihenfolge liest. Zuerst vergleicht er den Deckblatt-Titel und Seite 1 mit den Vorbedingungen: Build, URL und abgemeldeter Zustand. Danach liest er jede Prüfpunktseite und vergleicht die Zeile „Tatsächlich“ mit dem Screenshot.

Drittens prüft er, ob der Status auf dem Deckblatt zu den Seiten passt. Ein Protokoll mit Status Pass und einem roten Fehlerbanner auf Seite 5 geht an den Tester zurück. Ein Protokoll mit Status Fail ohne verknüpften Fehlerbericht geht ebenfalls zurück.

Blocked ist nicht Fail

Ein Test ist Blocked, wenn er aus einem Grund, der außerhalb des geprüften Verhaltens liegt, einen Prüfpunkt nicht erreicht. In TC-142 blockiert ein Ausfall der Staging-Umgebung, durch den die Reset-E-Mail nicht ankommt, Schritt 3. Das Protokoll zeigt den Startzustand und den letzten erreichbaren Bildschirm. Der Grund steht in der Beschreibung.

Ein blockierter Test als Fail zu markieren, verschlechtert die Fehlerquote und schickt einen Fehler an das falsche Team. Ihn als Pass zu markieren, verdeckt die Lücke. Behalten Sie Blocked als eigenen Status und führen Sie den Fall erneut aus, sobald der Blocker beseitigt ist.

Vom fehlgeschlagenen Prüfpunkt bis zum erneuten Test

Ein Fehlschlag folgt einem festen Ablauf. Das ursprüngliche Protokoll bleibt in jeder Phase unverändert.

Tastaturablauf für eine Testsitzung

Ein Tester, der 10 oder 20 Fälle in einer Sitzung durchführt, arbeitet effizienter, wenn er auf der Tastatur bleibt. Die folgenden Tasten decken Aufnahme und ersten Bearbeitungsdurchgang ab.

Aufbewahrung der Protokolle auf dem Mac

Dokumente bleiben auf dem Mac, mit dem sie erstellt wurden. Die Rohsitzungen bleiben im Capture History bis zur Obergrenze der Aufbewahrung. Die Standardgrenze liegt bei 30 Sitzungen und lässt sich unter Settings > History zwischen 1 und 500 einstellen. Ein intensiver Testzyklus kann 30 Sitzungen in wenigen Tagen überschreiten. Exportieren Sie jedes Protokoll daher in das Testmanagement-Tool, sobald der Fall abgeschlossen ist.

Häufig gestellte Fragen

Reichen Screenshots als Testnachweis aus?

Bei manuellen UI-Tests sind sie ein zentraler Bestandteil. Ergänzen Sie Logs, Konsolenausgaben oder Netzwerkdaten als Text, wenn ein Fehler auf dem Bildschirm nicht sichtbar ist. Siehe Screenshot-Nachweis.

Sollten automatisierte Tests ebenfalls Screenshots erzeugen?

Automatisierte Suiten erfassen meist Screenshots bei Fehlern. Für den automatischen Vergleich von Screenshots zwischen Builds siehe visuelles Regressionstesting.

Wie melde ich einen Fehler, der bei der QA gefunden wurde?

Schreiben Sie einen eigenen Fehlerbericht und verknüpfen Sie ihn mit dem Testfall. Siehe Einen Fehler mit Schritt-für-Schritt-Screenshots dokumentieren.

Wie viele Seiten sollte ein Testprotokoll haben?

Eine Seite für den Startzustand, eine pro Prüfpunkt und eine für jeden Fehler. TC-142 hat 4 Prüfpunkte, daher hat ein bestandenes Protokoll 5 Seiten.

Kann eine Prüfpunkt-Seite den Zeiger zeigen?

Ja. Aktivieren Sie Show cursor in shortcut captures in Configure Action Capture. Lassen Sie die Option deaktiviert, wenn die Zeigerposition für das Ergebnis keine Bedeutung hat.

Ihre Klicks in eine klare Schritt-für-Schritt-Anleitung verwandeln

Action Capture erfasst Prüfpunkte per Kürzel oder jeden Klick, je nach Lauf. Laden Sie Temposhot herunter und hängen Sie Ihr nächstes Testprotokoll als geordnetes PDF an.