// SOFTWARE
Testnachweis: warum ein Screenshot nicht reicht
6 Min. Lesezeitnijitech
Der umstrittenste Teil eines Testberichts ist nicht der gefundene Fehler, sondern ob der Test wirklich gelaufen ist. Ein Screenshot beweist das nicht; ein Ausführungsprotokoll schon.
Ganzer Beitrag
Der Bericht wird geliefert, der Kunde bleibt an einem Szenario hängen, und dieselbe Frage landet auf dem Tisch: „Wurde das wirklich getestet?“ Gibt es nichts als einen Screenshot, bleibt die Antwort dem Gedächtnis überlassen. Der Tester erzählt, was er getan hat, der Kunde ist nicht überzeugt; beide haben recht, denn keiner hat einen Beleg.
Dieser Beitrag beschreibt, wie dieser Streit verschwindet. Die Antwort sind nicht mehr Screenshots, sondern ein Protokoll darüber, was in welcher Umgebung und wann ausgeführt wurde, in einer Form, die sich nachträglich nicht ändern lässt.
Was ein Screenshot beweist und was nicht
Ein Screenshot zeigt einen Moment: So sah der Bildschirm in diesem Augenblick aus. Er sagt nicht, auf welchem Build, welchem Gerät und nach welchen Schritten er entstand. Er kann beschnitten, bearbeitet oder aus einer anderen Sitzung übernommen sein. Er ist nützlich, wenn ein Fehler gefunden wurde; er zeigt nicht, dass die zwanzig Szenarien ohne Fehler wirklich durchlaufen wurden.
Vier Fragen, die ein Testnachweis beantworten muss
- In welcher Umgebung lief es: Betriebssystem, Build, Gerät, Browser, Firmware
- Welches Szenario wann begann und wann endete
- Ob die angehängten Dateien (Logs, Bildschirmaufzeichnung) nachträglich verändert wurden
- Wer das Protokoll wann geschrieben hat und ob es bearbeitet werden kann
Das Ausführungsprotokoll: drei Dinge zugleich festhalten
Die Lösung ist, das Protokoll nicht dem Menschen zu überlassen. Ein Agent auf dem Rechner des Testers nimmt den Umgebungs-Fingerabdruck, schreibt Start- und Endstempel jedes Szenarios und speichert eine Prüfsumme (Hash) jeder angehängten Datei. Der Tester ergänzt Screenshots, Logs und Reproduktionsschritte; beides geht in einem Paket hinaus.
Der entscheidende Punkt ist Unveränderlichkeit. Können weder Tester noch Plattform das Protokoll nachträglich bearbeiten, wird über einen abgelehnten Bericht anhand des Protokolls gestritten, nicht darüber, wer sich woran erinnert. Der Einspruch schaut auf dasselbe Protokoll; ein Tester, der Recht bekommt, wird bezahlt.
Unabhängigkeit: Finder und Behebender dürfen nicht dieselbe Partei sein
Das Team, das ein Produkt schreibt, kann es nicht unparteiisch testen; das ist kein Mangel, sondern Natur. Der Entwickler weiß, wie der Ablauf funktionieren soll, und folgt diesem Weg, ohne es zu merken. Der Nutzer weiß es nicht und geht einen anderen Weg. Unabhängiges Testen heißt deshalb nicht nur „jemand von außen soll schauen“: Wenn die Partei, die den Befund fand, auch die Korrektur prüft und nicht die Partei ist, die korrigiert hat, ist die Prüfung wirklich unabhängig.
Warum das Kontingent Teil des Nachweises ist
Unsichtbare Konkurrenz ist der Zwilling unsichtbarer Arbeit. Steht vorab fest, wie viele Tester ein Auftrag aufnimmt, investiert der Tester Zeit im Wissen, mit wie vielen er konkurriert; ist das Kontingent voll, verschwindet der Auftrag aus der Liste. Ist auch die Vergütung vorab fest und ändert sich nicht mit der Zahl gefundener Fehler, wird ein Auftrag ohne Fehler ebenfalls bezahlt: Bezahlt wird nicht der Fehler, sondern dass die Szenarien ausgeführt wurden.
Zusammenfassung
Vier Bedingungen für belegtes Testen
- Ein Screenshot ist Beleg für einen Fehler, nicht für einen Test
- Umgebung, Zeitstempel und Dateiprüfsummen schreibt ein Agent, und sie ändern sich nie
- Finder, Behebender und Prüfer sind nicht dieselbe Partei
- Kontingent und Vergütung stehen vorab fest; Einsprüche laufen über das Protokoll
In diesem Beitrag erwähnte Produkte
Aus dem Glossar: Bewertungssatz (Eval) · Menschlich freigegebene Entscheidung (Human-in-the-Loop)