Hallway-Test

Was macht Hallway-Test?

Der Name kommt daher, dass man eine Person auf dem Flur abfängt und ihr bei der Nutzung des Produkts zusieht. Hier ist die Person ein Unter-Agent, der die Implementierung, die Spezifikationen oder die Konversation, die den Code erzeugt hat, nicht gesehen hat – er kann also nicht wissen, was der Autor weiß. Er liest die Anforderungen und die Benutzerdokumentation, entscheidet, was passieren sollte, probiert es aus und berichtet, wo die Realität abweicht. Im Modama-Crawler wurden so an einem Nachmittag Tests im Umfang von zwanzig Experimenten gefunden, einschließlich Fehlern, die die Testsuite zementiert hatte.

Zwei Modi, oft kombiniert:

• Verhalten: Der Tester erstellt Testeingaben, schreibt vor der Ausführung seine Erwartung für jede auf, führt das Tool aus, vergleicht und klassifiziert.
• Per Augenmaß: Bei Ausgaben, die für Menschen bestimmt sind, steuert der Tester das Tool in einem echten Terminal und beurteilt Screenshots. Das fängt ein, was Textparsing nie sieht: Ausgaben, die aus dem Bild laufen, Rauschen, das das Signal übertönt, Zeilenumbrüche, ein Pager, der Diagnosen versteckt. Der mitgelieferte Treiber ${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py startet einen xterm unter einem virtuellen X-Server, sendet Tastenanschläge und macht Screenshots; er benötigt xvfb, xterm, xdotool und imagemagick (ImageMagicks import) installiert, die ein Devcontainer bereitstellen kann.

Eine ausgeliehene Checkliste, mit Dank: die elf CLI-Benutzerfreundlichkeitskriterien des MIT-lizenzierten cli-ux-tester Skills von ali5ter, in ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md, als zusätzlicher Durchlauf für Kommandozeilenwerkzeuge.

Vor dem Start

Klären Sie diese Punkte mit dem Benutzer; sie werden das Briefing des Testers:

1. Was der Tester lesen darf. Nur das, was ein erster Benutzer hätte: die Anforderungen, die Benutzerdokumentation, die Hilfe des Befehls. Benennen Sie die Dateien oder Verzeichnisse; verbieten Sie den Rest explizit (Quellcode, Tests, Spezifikationen, Entwurfsnotizen, Git-Verlauf). Der Sinn des Tests ist die frische Sicht; jedes zusätzliche Dokument schwächt sie.
2. Das Werkzeug und wie man es ausführt. Die Befehlszeile oder der Einstiegspunkt, wo Testeingaben erstellt werden können (ein Scratch-Verzeichnis, niemals das Repository), was installiert werden darf, was nicht berührt werden darf (ein schreibgeschützter Daten-Mount ist schreibgeschützt).
3. Die abzudeckenden Fälle, auf denen bestanden wird. Eine Liste von Fällen, die der Tester abdecken muss, aus den Anforderungen und aus den Lücken des letzten Play-Tests, plus „fügen Sie eigene Experimente hinzu“. Für Tests per Augenmaß: die Szenarien, die Terminalgröße, die zu drückenden Tasten.
4. Wer Fragen beantwortet. Der Tester fragt die Hauptsitzung, wenn die Anforderungen nicht sagen, was passieren soll; die Hauptsitzung antwortet aus dem Design und notiert, was sie nicht sicher beantworten konnte, als TODO-Einträge für den Eigentümer.
5. Der Ort des Berichts und die Länge der Zusammenfassung.

Das Briefing

Starten Sie im Hintergrund einen universellen Unter-Agenten mit einem Briefing, das aus der Vorlage in ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md erstellt wurde: die Persona („ein Forscher im Software-Engineering, der dies zum ersten Mal als kritischer Erstanwender ausprobiert“), die strengen Leseregeln, die Befehlsreferenz, wie ein Benutzer sie erhalten würde, die Methode (erstellen, die Erwartung zuerst aufschreiben, ausführen, vergleichen, klassifizieren als Übereinstimmungen / Fehler / überraschend aber vertretbar / Lücke / Frage), die obligatorische Abdeckung, die Anweisung zu fragen und die Berichtsstruktur. Für Tests per Augenmaß verwenden Sie das Briefing in ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md, das den Treiber beschreibt und darauf besteht, dass der Tester nur Screenshots beurteilt.

Modell: Ein günstigeres Modell reicht für den Tester per Augenmaß, der schaut und berichtet; der Verhaltenstester profitiert vom Modell der Sitzung, da er darüber nachdenkt, was passieren sollte.

Während der Ausführung

Beantworten Sie die Fragen des Testers aus dem Design, mit der Begründung, und teilen Sie ihm mit, wenn eine Frage einen Fehler aufgedeckt hat (dann beheben Sie den Fehler auf dem normalen Weg, mit seinem Test, und teilen Sie dem Tester mit, dass sich das Werkzeug geändert hat). Führen Sie eine laufende Liste dessen, was Sie nicht sicher beantworten konnten; diese gehen als Entscheidungen an den Eigentümer, nicht als Ihre Vermutungen.

Nachher

1. Lesen Sie den Bericht. Überprüfen Sie jede Fehlerbehauptung am Code, bevor Sie sie akzeptieren; ein Tester ohne Quellzugang beschreibt Symptome, und die Ursache kann anders sein.
2. Schreiben Sie die dauerhafte Aufzeichnung dort, wo das Projekt Entwurfsnotizen aufbewahrt (z. B. design/playtest.md): was aufgehalten hat, was mit seinem Test und Spezifikationsszenario behoben wurde, die gegebenen Antworten und eine TODO-Liste für den Eigentümer mit Ihrer Tendenz pro Punkt.
3. Beantworten Sie für jeden Fehler „was hätte das abgefangen“ und fügen Sie hinzu: einen Test, eine Regel, eine Prüfung. Ein Fehler ohne diese Antwort ist nur halb behoben.
4. Halten Sie die Bäume und Screenshots des Testers reproduzierbar: ein kleines Skript, das jedes Experiment erneut ausführt, gespeichert neben dem Bericht oder im Scratch-Verzeichnis, mit dem im Record genannten Pfad.

Regeln

• Der Tester ändert niemals das Repository, liest niemals, was ihm verboten wurde, und gibt im Bericht an, was ihm gegeben wurde, einschließlich allem, was die Testumgebung angehängt hat, das er nicht angefordert hat.
• Erwartungen werden vor der Ausführung geschrieben, sonst ist der Vergleich bedeutungslos.
• Ein Befund ist ein Moment: der genaue Befehl, was erwartet wurde, was beobachtet wurde, die relevanten stderr-Zeilen oder der Screenshot-Dateiname.
• Beheben Sie während des Tests nicht, was der Tester als Frage gemeldet hat; entscheiden Sie zuerst, ob es ein Fehler oder eine Designentscheidung ist, dann beheben Sie es mit seinem Test.