"Como transformar \"o que o app faz\" numa lista de regras que dá pra provar"

"Sistema que só funcionavam usando uma conta específica. Qualquer outra conta retornava erro."

Quem escreveu foi um dev brasileiro contratado pra arrumar um sistema feito no vibe coding, num relato que está na pesquisa deste blog. É um caso, não estatística. Mas repara no que aconteceu: o dono testou, funcionou, publicou. Funcionou com a conta dele, a única que ele usava. A regra "qualquer conta nova consegue usar o app" nunca foi escrita, então nunca foi conferida.

A descrição do app não é uma lista de regras

Pergunta pra qualquer dono o que o app dele faz e vem um parágrafo: "é um app pra pequenos negócios controlarem o caixa; o cliente cadastra as vendas e, se for assinante, recebe o relatório do mês". Serve pra explicar o app num almoço. Pra testar, não: nenhuma frase ali tem resposta de sim ou não.

"Controlar o caixa" passa ou falha conforme o humor de quem confere. É por isso que você testa o botão e publica: sem regra escrita, o teste vira "clicar e ver se parece certo".

Não é falta de capacidade sua. Times de software resolveram isso há anos com um formato próprio, e ninguém te entregou ele traduzido. O mais conhecido se chama Gherkin, usado pela ferramenta de teste Cucumber, e descreve cada regra em três partes. A documentação oficial define assim: o Dado descreve "o contexto inicial do sistema", o Quando descreve "um evento, ou uma ação", e o Então descreve "um resultado esperado". Existe versão oficial em português, com essas palavras mesmo, e a documentação recomenda escrever na língua de quem conhece o negócio, sem traduzir. Ou seja: a sua.

Isso é convenção de time de software e não prova nada sobre o seu app. Você não precisa instalar Cucumber nenhum, só usar o molde.

Faz hoje: cinco passos, uma folha

Passo 1. Escreva o parágrafo do almoço. Do jeito que explicaria pra um amigo.

Passo 2. Sublinhe cada promessa. Todo verbo que o app faz pra alguém é uma regra escondida. No exemplo: "cadastra as vendas", "se for assinante", "recebe o relatório do mês". Três sublinhados, três regras pra escrever.

Passo 3. Reescreva cada uma no molde.

Dado [quem, em que situação]
Quando [faz o quê]
Então [o que aparece na tela, com número se tiver]

Pra saber se ficou provável, passe a frase por três perguntas:

• Tem um "quem" concreto? "O usuário" é vago. "Um cliente com plano mensal pago" dá pra criar.
• Tem uma ação que alguém faz? Clicar, salvar, pagar, abrir. "O sistema gerencia" não é ação.
• O resultado se vê? Se a frase tem "corretamente", "rápido", "fácil" ou "bem", ela ainda não é regra. Troque pelo que aparece: o número, a mensagem, a tela.

Lado a lado:

A terceira é a do relato lá de cima. Ela nem estava na descrição: apareceu quando perguntei "pra quem isso precisa funcionar?".

Passo 4. Dê a cada regra o seu "não". Toda regra que libera alguma coisa tem uma irmã que bloqueia. "Cliente com plano vê o relatório" pede a outra: "cliente sem plano não vê o relatório". O defeito caro mora na segunda, porque você testa com a própria conta, que tem tudo liberado. Se a regra envolve dado de uma pessoa, a irmã é "outra conta não vê", e o jeito de conferir é o teste das duas contas.

Passo 5. Use a mesma lista pra duas coisas.

Ela é o seu roteiro de teste: cada linha vira um quadradinho, e você só marca quando fez o Dado, fez o Quando e viu o Então. A regra com número é candidata a virar teste automático, e o nome dele é a própria frase.

E ela é o seu pedido pra IA. A documentação do Claude Code, a ferramenta de programação da Anthropic, diz que sem uma conferência que dê passou ou falhou, "você vira o ciclo de verificação" e cada erro espera você notar. O exemplo que ela mesma dá de pedido bom é uma lista de casos com a resposta certa ao lado. Vale pra qualquer ferramenta:

Implemente o que falta para estas regras valerem.
Não mexa em nada fora delas.

1. Dado um cliente com plano pago, quando abre Relatórios,
   então vê o relatório do mês.
2. Dado um cliente sem plano, quando abre Relatórios,
   então vê a tela de assinar, e não o relatório.

Para cada regra, escreva um teste com o nome igual à frase,
rode todos e cole a saída inteira.

Repara que a lista já responde a primeira pergunta da definição de pronto, "fez o que eu pedi?". Sem a regra escrita, essa pergunta não tem resposta. Com ela, é sim ou não.

Hoje, pegue o parágrafo do seu app e chegue em dez regras, cinco com o "sim" e cinco irmãs com o "não". Guarde a folha: toda função nova entra nela antes de ir pro pedido.

Era uma parede de várias

A lista diz o que o app promete. Ela não diz quais regras merecem conferência em toda rodada e quais podem esperar, e isso tem critério próprio, contado aqui. Também não protege o login, não garante que o código e o banco estão numa conta sua e não te diz se alguém de fora consegue usar sem você do lado. Escrever as regras é o D do ciclo que eu uso, definir. Depois vêm o pedido em fatia pequena, a prova e o app no ar, cada um com a sua folha.

Fontes

• Cucumber, "Gherkin Reference" (Dado descreve o contexto inicial, Quando um evento ou ação, Então o resultado esperado; escrever na língua de quem conhece o negócio, sem traduzir). É documentação de ferramenta de teste, não mede apps feitos com IA: https://cucumber.io/docs/gherkin/reference/
• Cucumber, "Localisation" (palavras-chave oficiais em português: Dado, Quando, Então, Cenário): https://cucumber.io/docs/gherkin/languages/
• Claude Code Docs, "Best practices for Claude Code" (sem uma conferência que dê passou ou falhou, "you become the verification loop"; exemplo de pedido com casos de teste e a resposta esperada): https://code.claude.com/docs/en/best-practices