Workflow de Revisão de TC
Conteúdo
- Lista de verificação de progresso
- Disciplina
- A Lei de Ferro
- Recusa primeiro (portão de pré-condição)
- Passo 1 — Carregar ambas as fontes na íntegra [liberdade média]
- Passo 2 — Construir a matriz de rastreabilidade [liberdade média]
- Passo 3 — Verificação de qualidade das linhas [liberdade média]
- Passo 3b — Varredura de fontes antes de 'perguntar ao PO/reporter' (obrigatório) [baixa liberdade]
- Passo 4 — Relatório Bom vs Precisa Melhorar [liberdade média]
- Passo 5 — Notificar o canal TC-review do projeto [baixa liberdade]
- Encerramento de QA (obrigatório antes de 'concluído') [baixa liberdade]
- Composição da skill
- Fora de escopo
- DEVE / NUNCA
- Arquivos de leitura obrigatória
- Dependências
Julgue um documento de caso de teste que alguém já escreveu — este workflow nunca projeta ou edita casos de teste por si só. Ele responde a uma pergunta: este documento, como escrito, prova que os AC/EC e regras de negócio do ticket serão verificados?
Atalho de comando slash (runtimes que suportam comandos): /tc-review → commands/tc-review.md.
Lista de verificação de progresso
Copie este bloco na sua resposta quando a execução começar e marque cada linha conforme for concluída. Um portão com falha envia você de volta ao passo cujo Voltar para: nome ele indica — desmarque a partir daí.
Progresso da revisão de TC:
- [ ] Recusa primeiro (portão de pré-condição)
- [ ] Passo 1 — Carregar ambas as fontes na íntegra
- [ ] Passo 2 — Construir a matriz de rastreabilidade
- [ ] Passo 3 — Verificação de qualidade das linhas
- [ ] Passo 3b — Varredura de fontes antes de 'perguntar ao PO/reporter' (obrigatório)
- [ ] Passo 4 — Relatório Bom vs Precisa Melhorar
- [ ] Passo 5 — Notificar o canal TC-review do projeto (perguntar apenas a thread)
- [ ] Encerramento de QA (obrigatório antes de 'concluído')
Disciplina
Siga shared-preamble.md e shared-must-never.md.
A Lei de Ferro
NENHUM ACHADO SEM UMA FONTE CITADA EM AMBOS OS LADOS
Cada achado compara duas coisas que foram realmente abertas nesta sessão: o texto do próprio documento de TC, e o texto do próprio AC/EC/regras de negócio do ticket (ou uma fonte de design como Figma/PRD, somente depois de realmente aberta). 'O TC parece incompleto' vindo de um senso geral de qualidade, sem a redação do próprio ticket citada ao lado, não é um achado — leia o ticket, depois julgue. Uma afirmação de fonte de design (texto de cópia exato, estado exato de UI) sem uma fonte realmente aberta nesta sessão também não é um achado — diga 'não verificado — não foi possível abrir {fonte}' em vez de adivinhar.
Esta é a mesma disciplina que o catch-ai-workflow executa para trabalho finalizado em geral; este workflow é sua
instância específica para TC, executada antes da execução, em vez de depois.
Recusa primeiro (portão de pré-condição)
NÃO DEVE começar sem ambos:
- o documento de TC — uma planilha, CSV ou arquivo markdown, acessível e legível nesta sessão;
- o ticket de governança — uma chave de issue do Jira ou URL contendo AC/EC (ou uma fonte de especificação equivalente que o usuário nomeie explicitamente).
🔴 PARE — faltando qualquer um, pare em uma mensagem conforme skill-rules-style.md.
Ticket entre organizações / sites: se o ticket reside em um site Atlassian ao qual o MCP conectado não recebeu acesso, informe e peça ao usuário para concedê-lo (ou cole os AC/EC diretamente) — nunca adivinhe um cloud id, nunca recorra a um login de navegador para lê-lo.
Passo 1 — Carregar ambas as fontes na íntegra [liberdade média]
- Documento de TC — leia-o como ele realmente é; não redigite, resuma ou 'limpe' a redação ao carregá-lo. Anote a fonte exata (id da planilha + aba/gid, caminho do arquivo ou URL) para que cada citação posterior possa apontar para ela.
- Ticket — busque AC, EC e quaisquer seções de regras de negócio / lista de recheck dos campos
próprios do ticket (descrição, campos personalizados — alguns projetos mantêm o conteúdo fora da
description; verifique ambos). Cite os rótulos e o texto de AC/EC exatamente como escritos; nunca parafraseie de memória de um ticket semelhante. Nenhum AC/EC encontrado em nenhum dos lugares → pare conforme o portão de recusa primeiro. Texto de especificação encontrado, mas seus itens não carregam rótulos de AC/EC → 🔴 PARE — mostre o texto encontrado e peça ao usuário como numerá-lo antes do Passo 2; nunca invente rótulos. O ticket ou documento de TC apresenta erro de busca, tempo limite ou retorna conteúdo parcial (texto truncado, campos ausentes, abas que não carregam) → informe ao usuário o erro exato ou o que está faltando, não construa a matriz a partir de AC/EC parciais ou de um documento de TC parcial, passe a falha parasuperpowers:systematic-debugging, e retome o Passo 1 somente quando o texto completo carregar. - Se uma fonte de design (Figma, PRD) está vinculada e o usuário deseja que ela seja verificada, abra-a nesta sessão. Se não puder ser aberta (sem sessão, sem acesso, somente leitura sem conteúdo renderizado), registre isso claramente — torna-se uma nota 'não verificado' ao lado de qualquer achado relacionado, nunca uma omissão silenciosa.
Passo 2 — Construir a matriz de rastreabilidade [liberdade média]
Para cada AC e EC no ticket, liste qual(is) linha(s) de TC afirmam cobri-lo:
| AC/EC | Afirmado por | Status |
|---|---|---|
AC_01 | TC_003 | coberto |
AC_05 | — | nenhum TC — lacuna |
AC_02 | TC_007 | marcado incorretamente — TC_007 Resultado Esperado corresponde a AC_04 |
EC_01 | TC_010, TC_011 | tag inconsistente — linha irmã TC_012 testa o mesmo elemento sem tag |
Status é uma lista fechada — use exatamente um destes quatro valores por linha, nomeando os ids como
mostrado:
coberto · nenhum TC — lacuna · marcado incorretamente — <TC> corresponde a <AC/EC> · tag inconsistente — <ids dos TC>.
Uma linha com vários problemas assume o primeiro que se aplica nessa ordem após coberto. Um buraco na
própria lista de AC do ticket é uma lacuna no nível da especificação, não uma linha da matriz — relate-o em
Precisa Melhorar como uma pergunta de especificação (veja DEVE / NUNCA).
AC/EC riscados não contam. Uma linha que o ticket riscou (ex.: -AC_07-, frequentemente marcada como
duplicata) está fora de escopo: deixe-a de fora da matriz e de todo o relatório. Não a mencione, nem
mesmo como 'corretamente não coberta'.
Regras de negócio e comentários do ticket são contexto, não AC extras. Leia-os para entender o que um AC/EC significa, e use-os para julgar se um TC testa a coisa certa. Relate um item de regra de negócio ou comentário somente quando ele conflitar com um AC/EC, e nomeie o AC/EC que ele contradiz. Uma regra ou comentário que não tem TC mas não contradiz nenhum AC/EC não é um achado. Deixe-o de fora de Precisa Melhorar, e não adicione uma seção de 'notas de especificação' para ele.
Sinalize, com os ids da linha/AC nomeados:
- um AC/EC com zero TCs;
- um TC cujo Resultado Esperado corresponde verificavelmente a um AC diferente daquele com o qual está marcado;
- o mesmo tema (ex.: um elemento de UI compartilhado) marcado inconsistentemente entre linhas irmãs — algumas carregam um AC, algumas não carregam nenhum, sem uma razão declarada.
Passo 3 — Verificação de qualidade das linhas [liberdade média]
Aplique tc-quality-standards.md a cada linha, lendo para estas formas de falha específicas de revisão (distintas da qualidade de autoria — trata-se de um documento escrito por outra pessoa, então a questão é se ele pode ser confiável, não se é elegante):
| Sinal | Por que é importante |
|---|---|
| Os passos não alcançam o estado que o título afirma. Uma linha intitulada 'Aprendiz visualiza X' cujos passos param na página principal nunca abre X. | O caso não pode verificar o que diz verificar. |
| O Resultado Esperado é a própria frase do AC, copiada na íntegra, sem decomposição. Quando o ticket lista vários subitens concretos (campos, estados, variantes de botão) sob aquele AC, um Resultado Esperado que apenas repete a frase do AC não dá ao testador nada para verificar linha por linha. | Aprovação/reprovação torna-se um palpite. |
| O AC enumera casos/estados nomeados (ex.: 'caso 1–6', estados 'carregando / vazio / filtro') e o documento tem uma linha genérica para todos eles. | A maioria dos estados enumerados permanece não testada mesmo que a linha esteja marcada como concluída. |
| Os Dados de Teste não têm valor concreto onde o AC precisa de um (um limite de contagem, uma relação de data específica, uma opção de filtro nomeada). | A linha não pode ser executada como escrita — o testador teria que inventar o valor faltante. |
| A linha testa uma condição diferente da redação do AC. O AC diz 'já rolou para passar' mas a linha usa 'assistiu até o fim'. O AC diz 'apenas itens publicados' mas o Resultado Esperado nunca verifica o status. | A linha pode ser aprovada enquanto a própria condição do AC permanece não testada. |
| O Resultado Esperado é mais vago do que os próprios Dados de Teste da linha permitem. Os Dados de Teste fornecem todas as entradas necessárias para computar a resposta (pontuações, contagens, uma fórmula), mas o Resultado Esperado apenas diz 'ordenado corretamente'. | O testador tem que descobrir o valor esperado durante a execução, então uma ordem errada ainda pode ser marcada como aprovada. |
| As colunas da linha se contradizem. A Pré-condição diz '4 itens' mas os Dados de Teste listam 3. O título diz 'status' mas o Resultado Esperado verifica apenas a ordem. | Qualquer coluna que o testador siga, a outra está errada. |
| Uma Pré-condição do ticket está faltando em todas as linhas (ex.: 'usuário está logado'). | Cada linha herda uma etapa de configuração não declarada. |
| A configuração nomeia um método sem fornecê-lo ('há uma maneira de fazer a requisição falhar', 'prepare dados suficientes'). | Dois testadores configurarão de duas maneiras diferentes. |
Não sinalize escolhas de estilo de caso de teste que não afetam se o caso pode ser confiável (convenção de nomenclatura, ordem de colunas, rótulos de prioridade) a menos que o usuário peça especificamente uma revisão de estilo. Isso substitui tc-quality-standards.md aqui: ignore seu atributo de Prioridade e sua linha de portão de revisão 'Prioridades atribuídas' a menos que o usuário peça uma revisão de estilo.
Passo 3b — Varredura de fontes antes de 'perguntar ao PO/reporter' (obrigatório) [baixa liberdade]
Este workflow nunca decide um veredito de produto, mas levanta lacunas e perguntas no nível da especificação.
Antes de qualquer achado se tornar 'perguntar ao PO/reporter' ou 'especificação pouco clara', execute a
varredura de fontes na camada 14 de result-quality-gate.md: o
código do produto no branch padrão com path:line, seus comentários inline e git log -L / blame; o ticket
principal e cada comentário; os tickets ao redor (pai / épico, vinculados, irmãos na mesma tela ou API, e
tickets que as mensagens de commit nomeiam); resultados de regressão; e o nó de design. Cite o que foi lido
ao lado do achado. Uma pergunta que as fontes já respondem é um achado com sua fonte, não uma pergunta.
Clone do produto ausente ou ilegível (a verificação {MONOREPO} em
dependencies.md falha): não pare a revisão e não pule a camada de código
silenciosamente. Escreva código não verificado — sem clone ao lado de cada pergunta que a camada de código
teria respondido, continue a varredura com as fontes restantes, e nunca apresente tal pergunta como
varredura-completa — ela vai para o Passo 4 carregando essa nota.
Saída por item: o achado (ou a pergunta restante) + a fonte citada com sua localização
(path:line, chave do ticket + comentário, linha de regressão, nó de design), ou a nota código não verificado — sem clone
quando a camada de código não pôde ser executada.
Voltar para: Uma pergunta que a varredura responde retorna ao Passo 2 ou 3 como um achado com fonte; somente uma pergunta que nenhuma fonte responde vai para o Passo 4 como 'confirmar com dev/PO'.
Passo 4 — Relatório Bom vs Precisa Melhorar [liberdade média]
Duas listas curtas, cada marcador ancorado a um id de linha, id de AC ou texto citado — nunca uma opinião sem âncora.
**Bom**
- {achado, com id do TC/AC ou citação}
**Precisa Melhorar**
- {achado, com id do TC/AC ou citação}
→ Sugestão: {como corrigir}
Cada marcador de Precisa Melhorar carrega uma linha '→ Sugestão:' que diz como corrigi-lo. Um problema sem correção deixa o autor do TC adivinhando. Cada sugestão deve vir de uma fonte, nunca de um valor inventado:
- Calculado a partir dos próprios dados da linha: quando os Dados de Teste já contêm as entradas, calcule o valor e forneça-o (ex.: a ordem esperada com cada pontuação calculada). Mostre os números para que o autor possa verificá-los.
- Extraído da redação do AC/EC: ex.: substitua a condição errada pela própria frase do AC, ou adicione a cláusula de Resultado Esperado faltante usando o próprio texto do AC.
- Nenhuma fonte fornece o valor (um limite, uma contagem ou um timing que o ticket nunca declara): sugira adicionar o valor e diga quem o confirma ('confirme a contagem com dev/PO'). Nunca invente um número.
Mantenha cada marcador enxuto. A sugestão diz o que mudar, não uma linha reescrita. Se o usuário pedir para estreitar o escopo (ex.: 'descarte tudo sobre X'), regenere a lista dos Passos 2–3 com essa categoria removida — não edite manualmente a prosa de forma reativa, caso contrário a mesma categoria ressurgirá com redação diferente na próxima vez.
Idioma: corresponda ao idioma do próprio ticket / documento de TC por padrão. Misturado = os AC/EC do ticket e o documento de TC estão escritos em idiomas diferentes → pergunte ao usuário uma vez em qual idioma escrever a revisão. Menus Helix e perguntas de intake permanecem em inglês conforme user-communication.md; o conteúdo da revisão em si segue o idioma do documento de destino, a mesma exceção que esse documento já carrega.
Publique a revisão no chat antes do envio do Passo 5 — uma mensagem externa não pode ser desfeita como uma mensagem de chat pode. A pergunta da thread do Passo 5 é o sinal verde; não adicione uma pergunta separada 'enviar?'.
Passo 5 — Notificar o canal TC-review do projeto [baixa liberdade]
Cada execução envia a revisão finalizada para o canal TC-review
...
[truncado para tradução]