Plano de QA (Plano de Teste de Baseline)
Derive o plano de teste de baseline para uma História de Usuário por meio de exame socrático: condições de teste com técnicas de design declaradas, resultados esperados afirmados apenas quando as especificações os suportam, e perguntas direcionadas a quem pode resolver o restante. Você não pergunta "esta história está bem escrita?", isso é função de /refinar-história. Você responde: o que pode quebrar, como provo que funciona e o que deve existir para executar essa prova.
Um engenheiro de QA de nível pleno deve ser capaz de implementar testes diretamente a partir deste artefato; um engenheiro de QA sênior deve concordar com sua priorização.
HU: $ARGUMENTOS
Limite de três camadas
Derivar condições não escritas é a essência do QA, desde que siga métodos estabelecidos. Portanto, o limite aqui opera em três camadas; a base permanece rigor-requisitos. Cada condição no plano pertence exatamente a uma camada:
[ESPECIFICADO: trecho]: condição e resultado esperado originam-se diretamente do texto. Cite a fonte.[DERIVADO: técnica]: a condição decorre de uma técnica de design de teste aplicada ao que foi especificado. Sempre nomeie a técnica; uma condição sem técnica declarada é um palpite e não deve entrar. Resultados esperados só podem ser afirmados se seguirem logicamente da especificação.[INDEFINIDO → Pergunta n]: uma condição legítima cujo resultado esperado a especificação não define. A condição entra na matriz; o resultado torna-se uma pergunta numerada.
Teste rápido: "qual técnica gerou esta condição, e de qual trecho ela se origina?" Se qualquer uma delas não puder ser respondida, exclua-a do plano.
Antes de começar
Leia docs/agents/refinement.md no workspace: ele define o modo de operação (com ou sem código), idioma (en-US ou pt-BR, padrão en-US) e caminhos de publicação. O modo determina quem responde a perguntas arquiteturais: com código, você as resolve inspecionando o código-fonte; sem código, a equipe de engenharia as resolve por meio de questionários. O exame socrático e o plano de QA são escritos no idioma configurado. Se o arquivo estiver faltando, solicite /configure-refinement e pare.
Passos
-
Carregar. Leia a HU,
CONTEXT.md, ADRs de domínio, TESTE-DESIGN.md e invoque a ferramenta Skill pararigor-requisitos. Se.scratch/<slug>/spec.mdexistir de/refinar-história, comece a partir dele: decisões dessa sessão já respondem a muitas perguntas. Sem esse arquivo, trate a HU como não refinada, mesmo queStatus:indique PRONTA. Concluído quando: a triagem de testabilidade é declarada em uma única linha: TESTÁVEL (cada resultado esperado tem um ponto de observação e nenhuma dependência está pendente de confirmação), TESTÁVEL COM RESERVAS (condições podem ser derivadas, mas ao menos um resultado carece de ponto de observação ou depende de dependências não confirmadas) ou NÃO TESTÁVEL. -
Triagem. NÃO TESTÁVEL (os critérios falham em descrever comportamento observável: exclusivamente tarefas, ou termos subjetivos sem métricas em todos os critérios): explique o que está faltando, liste 3 a 5 perguntas mínimas e recomende
/refinar-história. Pare aqui; analisar material não testável gera planos de fachada. Se a HU não passou por refinamento, declare isso e prossiga, observando que muitas perguntas seriam resolvidas por/refinar-história. Concluído quando: a triagem é declarada. -
Derivar condições. Para cada critério, aplique técnicas aplicáveis de TESTE-DESIGN.md, evitando forçar técnicas inaplicáveis, e revise ângulos silenciosos, relatando apenas os aplicáveis. Construa a matriz: condição, origem, resultado esperado ou
[INDEFINIDO → Pergunta n], prioridade, camada. Condições indefinidas permanecem na matriz: cobertura futura visível é muito melhor do que lacunas ocultas. Numere as perguntas em uma única sequência combinando PO e DEV, de modo que[INDEFINIDO → Pergunta n]resolva sem ambiguidade. As justificativas de prioridade (meia linha por condição) vão em uma lista dentro da seção de análise de riscos, não dentro da tabela. Concluído quando: toda condição tem uma origem declarada e todo[INDEFINIDO]tem um número de pergunta atribuído. -
Buscar fatos antes de perguntar. Separe as perguntas por destinatário. PO: comportamento de negócio indefinido. DEV: arquitetura, observabilidade, camada de teste, isolamento de dependências externas, controle de tempo, provisionamento de dados de teste, resposta de erro de API, persistência após falha, idempotência técnica. No modo com código, despache um subagente para responder perguntas DEV lendo código: a notificação é síncrona ou assíncrona? há um bloqueio na aprovação? existe um mock para o sistema externo? Um fato encontrado torna-se um resultado esperado ou camada definida, com citação da fonte. No modo sem código, a busca é restrita a arquivos do workspace sem subagentes; se nada for encontrado, declare isso em uma única linha no topo da rodada 1. Concluído quando: cada pergunta é marcada como respondida por uma fonte ou em aberto, com destinatário atribuído.
-
Examinar PO. Invoque a ferramenta Skill para
exame-socratico. A rodada de perguntas acompanha a matriz atual, pois as perguntas referenciam condições específicas. A fronteira consiste em perguntas PO, itens bloqueantes primeiro (aqueles que desbloqueiam condições P1), cada um com uma resposta recomendada quando as especificações fornecem base; quando ausente, forneça "sem recomendação" e opções. Respostas PO atualizam a matriz imediatamente. Desafie termos contra o glossário, mas registre emCONTEXT.mdapenas o que o PO resolver. Concluído quando: a fronteira de perguntas PO está vazia, ou o PO solicita encerramento. -
Sintetizar. Escreva o plano seguindo TEMPLATE.md: matriz, análise de riscos, cenários P1 em Gherkin com autoauditoria, auditoria de automatizabilidade, impacto de regressão baseado estritamente na documentação do sistema existente (sem contexto, liste perguntas de impacto para DEV), perguntas restantes por destinatário, veredito de cobertura. Concluído quando: o arquivo existe no caminho definido por
docs/agents/refinement.mdcom o aviso final presente. -
Encaminhar itens em aberto. Perguntas DEV abertas no modo sem código e perguntas PO abertas que não puderam ser respondidas: escreva um questionário por destinatário seguindo
QUESTIONARIO.mdemrigor-requisitos, junto com o plano, e vincule os arquivos das perguntas abertas. Concluído quando: nenhuma pergunta em aberto permanece sem destinatário ou questionário. -
Relatar. Veredito, onde o plano foi publicado, contagem de condições P1 executáveis, e o que cada questionário desbloqueia.
Aviso final
⚠️ Esta saída fornece a linha de base analítica para um plano de teste, não o plano de teste final. Decisões sobre cobertura, priorização e esforço pertencem à equipe de QA, com validação do PO (comportamentos indefinidos) e Dev (arquitetura e camadas).