test-hallway

Test hallway

Le nom vient de l'idée d'attraper une personne dans le couloir et de la regarder utiliser le produit. Ici, la personne est un sous-agent qui n'a pas vu l'implémentation, les spécifications ni la conversation qui a produit le code, afin qu'il ne puisse pas ignorer ce que l'auteur sait. Il lit les exigences et la documentation utilisateur, décide ce qui devrait se passer, essaie, et rapporte où la réalité diffère. Dans le crawler modama, cela a découvert vingt expériences de comportement en un après-midi, y compris des défauts que la suite de tests avait consacrés.

Deux modes, souvent combinés :

• Comportemental : le testeur construit des entrées de test, écrit son attente pour chacune avant d'exécuter, exécute le outil, compare, classe.
• Visuel : pour les sorties destinées aux humains, le testeur pilote le outil dans un terminal réel et juge les captures d'écran, ce qui capture ce que l'analyse textuelle ne voit jamais : sortie défilée, bruit noyant le signal, lignes qui se coupent, un pager cachant les diagnostics. Le pilote fourni ${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py démarre un xterm sous un serveur X virtuel, envoie des touches et prend des captures d'écran ; il nécessite xvfb, xterm, xdotool et imagemagick (import d'ImageMagick) installés, ce qu'un devcontainer peut transporter.

Une liste de contrôle empruntée, avec remerciements : les onze critères d'utilisabilité CLI du skill cli-ux-tester sous licence MIT par ali5ter, dans ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md, comme passe supplémentaire pour les outils en ligne de commande.

Avant le lancement

Régler ces points avec l'utilisateur ; ils deviennent le briefing du testeur :

1. Ce que le testeur peut lire. Seulement ce qu'un premier utilisateur aurait : les exigences, la documentation utilisateur, l'aide de la commande. Nommer les fichiers ou répertoires ; interdire explicitement le reste (source, tests, specs, notes de conception, historique git). Le but du test est le regard neuf ; chaque document supplémentaire l'affaiblit.
2. L'outil et comment l'exécuter. La ligne de commande ou le point d'entrée, où les entrées de test peuvent être créées (un répertoire temporaire, jamais le dépôt), ce qui peut être installé, ce qui ne doit pas être touché (un montage de données en lecture seule est en lecture seule).
3. La couverture à exiger. Une liste de cas que le testeur doit couvrir, à partir des exigences et des lacunes du dernier playtest, plus « ajoutez vos propres expériences ». Pour les tests visuels : les scénarios, la taille du terminal, les touches à appuyer.
4. Qui répond aux questions. Le testeur interroge la session principale lorsque les exigences ne disent pas ce qui devrait se passer ; la session principale répond à partir de la conception et enregistre ce qu'elle n'a pas pu répondre avec confiance comme TODOs pour le propriétaire.
5. L'emplacement du rapport et la longueur du résumé.

Le briefing

Générer un sous-agent polyvalent en arrière-plan avec un briefing construit à partir du modèle dans ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md : le persona (« un ingénieur en recherche logicielle essayant ceci pour la première fois, en tant qu'utilisateur précoce critique »), les règles de lecture strictes, la référence de commande telle qu'un utilisateur la recevrait, la méthode (créer, écrire d'abord l'attente, exécuter, comparer, classer comme correspondance / bug / surprenant mais défendable / lacune / question), la couverture obligatoire, l'instruction de demander, et la structure du rapport. Pour les tests visuels, utiliser le briefing dans ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md, qui décrit le pilote et insiste pour que le testeur juge uniquement les captures d'écran.

Modèle : un modèle moins cher suffit pour le testeur visuel, qui regarde et rapporte ; le testeur comportemental bénéficie du modèle de la session, car il raisonne sur ce qui devrait se passer.

Pendant l'exécution

Répondre aux questions du testeur à partir de la conception, avec le raisonnement, et lui dire quand une question a révélé un bug (puis corriger le bug normalement, avec son test, et dire au testeur que l'outil a changé). Tenir une liste courante de ce que vous n'avez pas pu répondre avec confiance ; ceux-ci vont au propriétaire comme décisions, pas comme vos suppositions.

Après

1. Lire le rapport. Vérifier chaque affirmation de bug dans le code avant de l'accepter ; un testeur sans accès au source décrit des symptômes, et la cause peut différer.
2. Écrire l'enregistrement persistant là où le projet garde les notes de conception (par exemple design/playtest.md) : ce qui a tenu, ce qui a été corrigé avec son test et son scénario de spec, les réponses données, et une liste de TODOs pour le propriétaire avec votre avis par élément.
3. Pour chaque défaut, répondre « qu'est-ce qui aurait attrapé cela » et ajouter cela : un test, une règle, une vérification. Un défaut sans cette réponse n'est qu'à moitié corrigé.
4. Conserver les arborescences et captures d'écran du testeur reproductibles : un petit script qui relance chaque expérience, sauvegardé à côté du rapport ou dans le répertoire temporaire, avec le chemin nommé dans l'enregistrement.

Règles

• Le testeur ne modifie jamais le dépôt, ne lit jamais ce qui lui a été interdit, et indique dans le rapport ce qui lui a été donné, y compris tout ce que le harnais a attaché qu'il n'a pas demandé.
• Les attentes sont écrites avant l'exécution, sinon la comparaison ne signifie rien.
• Un constat est un moment : la commande exacte, ce qui était attendu, ce qui a été observé, les lignes stderr pertinentes ou le nom de fichier de la capture d'écran.
• Ne pas corriger pendant le test ce que le testeur a rapporté comme question ; décider d'abord s'il s'agit d'un bug ou d'un choix de conception, puis corriger avec son test.