"O que testar e o que não testar: a lista de 5 fluxos que valem e os 50 que não"

"Com vibe coding, levei 1 hora codando e 10 horas testando e corrigindo erros."

Foi escrito no TabNews, o fórum brasileiro de tecnologia, e está na pesquisa deste blog. Relato de uma pessoa, não medição. Eu já fiz a conta de onde saem essas horas e quanto elas custam por mês. Este post é sobre outra coisa: o que entra no teste e o que fica de fora.

Porque o cansaço quase nunca vem de testar. Vem de testar tudo com o mesmo peso. Você confere a cor do botão com a mesma aflição com que confere o pagamento. O rodapé ganha o cuidado do login. São 50 coisas na cabeça, nenhuma ordem, e a sensação de que, se parar, alguma coisa quebra escondida.

Ninguém te deu o critério (e ele não é porcentagem)

Quem programa tem um número pra isso, a cobertura: a porcentagem do código que algum teste executa. E é aqui que a minha categoria te atrapalha, porque você vai ouvir "tem que ter 80% de cobertura" de alguém que nunca abriu o seu app.

O Google, que sugere faixas de cobertura pros próprios times, escreveu em agosto de 2020 no blog oficial de testes que "uma porcentagem alta de cobertura não garante qualidade" e que correr atrás de 100% "leva a uma falsa sensação de segurança". E disse o que decide quanto testar: o impacto daquele pedaço no negócio, quantas vezes você mexe nele e quanto tempo ele vai durar. O texto foi escrito pra times grandes de engenharia e não diz nada sobre o seu app em particular. Mas o critério vale igual: impacto, não porcentagem.

Traduzido pra quem não programa, são duas perguntas.

As duas perguntas

Pra cada coisa que o seu app faz:

1. Se isso quebrar, alguém perde dinheiro ou dado? O cliente paga e não recebe, cadastra e some, vê o que não devia.

2. Se isso quebrar, eu fico sabendo sozinho? Você esbarra no defeito no uso normal da semana, ou só descobre quando o cliente reclama (ou não reclama e some)?

As respostas desenham quatro casas:

Casa A, os 5 que valem. Perdem dinheiro ou dado e quebram em silêncio. Em quase todo app são os mesmos: entrar, cadastrar, salvar, cobrar, sair. Login que falha não avisa ninguém, a pessoa só desiste. Dado que não gravou parece gravado até alguém apertar F5. Pix que não libera vira três comprovantes no seu WhatsApp. Sessão que não fecha mostra o painel pro próximo que sentar no computador. Esses cinco rodam antes e depois de todo pedido à IA, e o roteiro com o que precisa aparecer em cada linha está aqui.

Casa B, quando mexer. Envolvem dinheiro, mas você usa todo dia e vê o defeito na hora: o painel onde confere os pedidos, o relatório do mês. Entram na rodada só quando o pedido à IA encostou neles.

Casa C, uma vez por mês. Não perdem nada, mas ninguém te avisa: o e-mail de boas-vindas com o logo quebrado, o link morto na página de termos, a tela que desalinha só em celular pequeno. Uma passada mensal, com calma, numa lista separada.

Casa D, os que não valem. Não perdem nada e você vê na hora: a cor do botão, o alinhamento do título, o texto do rodapé, a animação de carregando, a página "sobre". Quebrou, você percebe no mesmo dia e pede o conserto. Conferir isso em toda rodada é o que transforma 2 minutos em 45.

Repara: a maioria das 50 mora na casa D. É por isso que testar tudo cansa tanto e protege tão pouco.

Faz hoje: o inventário de 10 minutos

1. Liste tudo que o app faz, numa nota, do jeito que vier: telas, botões, e-mails, relatórios. Não filtre. Passa fácil de 30 linhas.
2. Escreva a letra da casa do lado de cada linha: A, B, C ou D. Na dúvida entre duas, fique com a mais grave.
3. Conte as linhas A. Passou de sete? Você marcou como A alguma coisa que é B. Volte e pergunte de novo, com honestidade, se você realmente não ficaria sabendo.
4. Distribua. As A viram o roteiro fixo. As B viram uma lista "quando mexer em…". As C ganham um lembrete mensal no celular. As D você risca, sem culpa.

Guarde a folha. Ela muda pouco, e muda num momento só: quando o app ganha uma função que mexe com dinheiro ou dado. Essa função entra direto na casa A, no dia em que nasce.

O que o mapa não resolve

Ele diz o que conferir. Não diz como conferir cada linha A direito. O cadastro tem as entradas maldosas que ninguém pensa sozinho. O "ver o que não devia" tem o teste das duas contas. A regra com número, o total e o desconto, merece virar teste automático em vez de clique.

Isso é o D do ciclo que eu uso, definir: antes de testar melhor, decidir o que merece teste. É a primeira de várias decisões que, tomadas fora de ordem, viram as 10 horas de clique. Na ordem, cada uma cabe numa folha.

Fontes

• Relato "1 hora codando e 10 horas testando", TabNews (registrado na pesquisa do blog, pesquisa/03-swipe-file-verbatim.md)
• Google Testing Blog, "Code Coverage Best Practices", Carlos Arguelles, Marko Ivanković e Adam Bender, 08/2020 (cobertura alta não garante qualidade; 100% dá falsa sensação de segurança; quanto testar depende de impacto no negócio, frequência de mudança e tempo de vida do código): https://testing.googleblog.com/2020/08/code-coverage-best-practices.html