hallway-test

Teste de corredor

O nome vem de agarrar uma pessoa no corredor e observar como ela usa o produto. Aqui a pessoa é um subagente que não viu a implementação, as especificações ou a conversa que produziu o código, portanto não pode desaprender o que o autor sabe. Ele lê os requisitos e a documentação voltada ao usuário, decide o que deveria acontecer, tenta executar e relata onde a realidade difere. No crawler modama, isso encontrou vinte experimentos de comportamento em uma tarde, incluindo defeitos que a suíte de testes havia consagrado.

Dois modos, frequentemente combinados:

• Comportamental: o testador constrói entradas de teste, escreve sua expectativa para cada uma antes de executar, executa a ferramenta, compara e classifica.
• Visual: para saída destinada a pessoas, o testador opera a ferramenta em um terminal real e julga capturas de tela, o que captura o que a análise textual nunca vê: saída cortada, ruído abafando o sinal, linhas quebrando, um pager escondendo diagnósticos. O driver incluído ${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py inicia um xterm sob um servidor X virtual, envia teclas e tira capturas de tela; ele precisa de xvfb, xterm, xdotool e imagemagick (o comando import do ImageMagick) instalados, o que um devcontainer pode fornecer.

Uma lista de verificação emprestada, com agradecimentos: os onze critérios de usabilidade CLI do skill cli-ux-tester (licença MIT) por ali5ter, em ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md, como uma passagem extra para ferramentas de linha de comando.

Antes de lançar

Combine estes itens com o usuário; eles se tornam o resumo do testador:

1. O que o testador pode ler. Apenas o que um primeiro usuário teria: os requisitos, a documentação do usuário, a ajuda do comando. Nomeie os arquivos ou diretórios; proíba explicitamente o restante (código fonte, testes, especificações, notas de design, histórico do git). O objetivo do teste é a visão nova; cada documento extra a enfraquece.
2. A ferramenta e como executá-la. A linha de comando ou ponto de entrada, onde as entradas de teste podem ser criadas (um diretório temporário, nunca o repositório), o que pode ser instalado, o que não deve ser tocado (um ponto de montagem de dados somente leitura é somente leitura).
3. A cobertura a ser insistida. Uma lista de casos que o testador deve cobrir, a partir dos requisitos e das lacunas do último playtest, além de "adicione experimentos próprios". Para testes visuais: os cenários, o tamanho do terminal, as teclas a pressionar.
4. Quem responde perguntas. O testador pergunta à sessão principal quando os requisitos não dizem o que deveria acontecer; a sessão principal responde a partir do design e registra o que não pôde responder com confiança como itens TODO para o proprietário.
5. O local do relatório e o tamanho do resumo.

O resumo

Gere um subagente de propósito geral em segundo plano com um resumo construído a partir do modelo em ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md: a persona ("um engenheiro de software de pesquisa tentando isso pela primeira vez, como um usuário inicial crítico"), as regras estritas de leitura, a referência do comando como um usuário a receberia, o método (criar, escrever a expectativa primeiro, executar, comparar, classificar como correspondência / bug / surpreendente mas defensável / lacuna / pergunta), a cobertura obrigatória, a instrução para perguntar e a estrutura do relatório. Para testes visuais, use o resumo em ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md, que descreve o driver e insiste que o testador julgue apenas capturas de tela.

Modelo: um modelo mais barato é suficiente para o testador visual, que observa e relata; o testador comportamental se beneficia do modelo da sessão, pois raciocina sobre o que deveria acontecer.

Enquanto executa

Responda às perguntas do testador a partir do design, com o raciocínio, e informe-o quando uma pergunta expuser um bug (então corrija o bug da maneira normal, com seu teste, e diga ao testador que a ferramenta mudou). Mantenha uma lista contínua do que você não pôde responder com confiança; esses itens vão para o proprietário como decisões, não como seus palpites.

Depois

1. Leia o relatório. Verifique cada alegação de bug em relação ao código antes de aceitá-la; um testador sem acesso ao código fonte descreve sintomas, e a causa pode ser diferente.
2. Escreva o registro persistente onde o projeto mantém notas de design (por exemplo, design/playtest.md): o que funcionou, o que foi corrigido com seu teste e cenário de especificação, as respostas dadas e uma lista TODO para o proprietário com sua opinião por item.
3. Para cada defeito, responda "o que teria capturado isso" e adicione: um teste, uma regra, uma verificação. Um defeito sem essa resposta está apenas parcialmente corrigido.
4. Mantenha as árvores e capturas de tela do testador reproduzíveis: um pequeno script que reexecuta qualquer experimento, salvo ao lado do relatório ou no diretório temporário, com o caminho nomeado no registro.

Regras

• O testador nunca modifica o repositório, nunca lê o que lhe foi proibido e informa no relatório o que recebeu, incluindo qualquer coisa que o harness anexou e que ele não solicitou.
• As expectativas são escritas antes da execução, ou a comparação não significa nada.
• Uma descoberta é um momento: o comando exato, o que era esperado, o que foi observado, as linhas relevantes do stderr ou o nome do arquivo de captura de tela.
• Não corrija durante o teste o que o testador relatou como uma pergunta; decida primeiro se é um bug ou uma escolha de design, depois corrija com seu teste.