Testar software não é sair clicando: o que a teoria realmente ensina?

Leitura: ~4 minutos • 🎧 resumo em áudio:

TL;DR

• Testar software não é executar passos à toa; é construir evidências sobre risco e comportamento.
• Qualidade não nasce da cobertura de código ou do número de cliques; nasce de testes planejados contra regras de negócio.
• Níveis, técnicas e pirâmide de testes importam porque cada um encontra defeitos em camadas diferentes.
• O erro mais comum é validar só o cenário feliz e ignorar limites, arredondamentos, cancelamentos e exceptions reais.

~ 4 min de leitura · 688 palavras

🤖 Peça a uma IA resumir e discutir este texto: ChatGPT • Claude

Um sistema passa em tudo e mesmo assim falha

Depois de décadas desenvolvendo e operando sistemas, eu não confio em frase do tipo: este sistema está testado. Teste nem prova que algo funciona em qualquer situação. Ele procura onde pode falhar. Um ERP pode passar em todos os cenários “normais” e ainda errar no dia em que alguém vende com desconto + arredondamento + item isento + cancelamento.

Teste, depuração, verificação e validação

Teste é executar software para encontrar defeitos. Depuração é corrigir o que já encontrou. Verificação pergunta se o produto foi construído conforme a especificação. Validação pergunta se o que foi construído resolve o problema do usuário.

Em prática de ERP, essa diferença importa. Se a regra de negócio exige arredondamento bancário, testar a tela não valida isso. Se a função de arredondamento opera em float, a tela pode passar e o fechamento contábil quebra.

Princípios que mudam o comportamento

1. Testes encontram defeitos, não garantem ausência deles. 2. Testes exaustivos são impossíveis. 3. Desenvolver testa o software apenas neutraliza parte do risco. 4. Bugs se concentram em áreas críticas. 5. O mesmo teste repetido deixa de encontrar algo novo. 6. Testes precisam mudar conforme o sistema evolui.

Níveis de teste e cortina de fumaça

• Unitário: foco na menor unidade de lógica (ex: método de cálculo de desconto).
• Integração: foco no encontro entre componentes (ex: serviço + repositório + registor fiscal).
• Sistêmico: foco no comportamento completo do produto final.
• Aceite: confirma se regras com o cliente real estão satisfeitas.

Técnicas: caixa-preta e caixa-branca

Caixa-preta não exige acesso ao código; foca em entrada/saída. Caixa-branca exige olhar dentro.

Exemplo de caixa-preta: “envio total R$ 1.000 ⇒ com desconto de 10% ⇒ resultado R$ 900”. Exemplo de caixa-branca: “se o método recebe token nulo, falha; se recebe cliente com limite bloqueado, recusa”.

Equivalência, limites e tabela de decisão

Equivalência: grupo de entradas com mesmo comportamento. Valores-limite: teste fronteiras (0, 1, max, min). Tabela de decisão: quando várias regras se aplicam simultaneamente, a matriz de combinações evita olhos cegos.

Exemplo ERP com descontos:

• cliente normal + desconto 5% + produto isento → impostos iguais.
• cliente normal + desconto 10% + produto tributado → arredondamento após multiplicação.
• cliente vip + desconto progressivo + item com CFOP diferente → trilha fiscal.

Pirâmide: por que UI não é tudo

Concentrar testes na interface é caro e frágil. A pirâmide prega: muitos unitários rápidos, menos integrações, ainda menos UI/E2E. Testes de abrir navegador para valida botão são caros, lentos e não descobrem erros em regras de negócio escondidas no backend.

Cobertura: percentual não é qualidade

100% de cobertura de linhas não testa todas as combinações. Se a função tem branches, um único caminho pode deixar a combinação mais perigosa sem ser testada. Melhor medir risco coberto do que linhas de código cobertas.

Regras de negócio viram cenários

Transformar requisito em cenário testável é a menos glamorosa e mais importante etapa da engenharia de testes. “Cliente pode cancelar em 24 horas” vira:

• cancelamento 23:59 ok
• 24:00:01 fail
• cliente sem liberação comercial: fail antes do cancelamento
• NF já manifestada: fail antes de cancelar

Exemplo completo: venda de R$ 1.000

Regras:

• Tela vende R$ 1.000, desconto 5%, arredondamento, produto isento, cancelamento em 1 dia, fiscal.

Cenários mínimos: 1. total bruto 1.000, desconto 50 = 950 — validar arredondamento. 2. item isento → imposto zero, trilha fiscal anterior. 3. item tributado com CFOP diferente → discriminar base de cálculo. 4. 24h limite exato — testar limite inclusive. 5. cancelamento depois de NF transmitida — testar refusal. 6. recuperação após falha de Save. 7. fatura parcial + desconto — validar cálculo parcial.

O erro mais comum

Testar o esperado é fácil. Qualidade é procurar onde o sistema quebra: valores incomuns, combinações de regras, sequências raras de operação, paralelismo e estados parciais.

Fechamento

É o que faço toda vez que inicio uma migração ou auditoria: identifico regras, defino riscos, desenho cenários e depois executo. Testar não é clicar; é raciocínio. Se eu tivesse que auditar um ERP hoje, três testes primeiro: limites de preço, cancelamento com NF transmitida e consistência fiscal. Qualquer falha nesses pontos é sinal de que a qualidade ainda não chegou ao ponto de produção.