Como projetar casos de teste que realmente encontram bugs

A resposta curta é esta: você projeta casos de teste que realmente encontram bugs quando para de improvisar entradas e passa a aplicar técnicas que cobrem o risco com poucos casos bem escolhidos. As três que mais rendem são classes de equivalência, análise de valores limite e tabelas de decisão. Elas não testam tudo, porque testar tudo é impossível; testam o que importa, e fazem isso de um jeito que qualquer pessoa consegue repetir.

Todo testador cedo ou tarde esbarra no mesmo muro: as combinações possíveis de um formulário simples já são mais do que você conseguiria executar em toda a sua vida. Um campo de idade que aceita números de 0 a 120, outro de país com 200 opções, um desconto que depende de três condições. Multiplique e o resultado é um número absurdo. Testar caso a caso não é meticulosidade, é render-se à força bruta. E a força bruta se esgota antes dos bugs.

01 · o problemaInfinitos testes possíveis, tempo finito

O ponto de partida do projeto de testes é aceitar uma verdade incômoda que o ISTQB coloca entre seus princípios fundamentais: o teste exaustivo é impossível, salvo em casos triviais. Você não consegue exercitar todas as entradas nem todas as combinações. Então a pergunta útil nunca é "como testo tudo?", e sim "qual pequeno subconjunto de testes me dá a maior confiança pelo menor esforço?".

É aqui que a intuição falha. Um testador experiente "sente o cheiro" de onde está o risco, mas essa intuição não se documenta nem se ensina. As técnicas de projeto fazem o contrário: transformam esse faro em um procedimento. Você dá as mesmas regras a duas pessoas e obtém quase os mesmos casos. É isso que significa reproduzível, e é o que separa uma suíte profissional de uma lista de palpites.

Testar tudo é impossível. Escolher bem o que testar é a habilidade inteira.

As técnicas a seguir são de caixa preta: você projeta os casos olhando para o que o sistema deve fazer, não para como está escrito por dentro. Você não precisa ler o código. Precisa entender a especificação e saber onde os erros costumam se esconder.

02 · classes e limitesParticione o problema e ataque as bordas

A primeira técnica é o particionamento em classes de equivalência. A ideia é simples e poderosa: você agrupa as entradas possíveis em classes onde o sistema deveria se comportar da mesma forma, e testa um único representante de cada classe. Se um campo de idade aceita 0 a 120, você tem três classes evidentes: os valores abaixo (inválidos), os válidos, e os acima (inválidos). Não é preciso testar 43 e 44 e 45; se o sistema trata bem o 44, tratará bem todos os seus vizinhos de classe. Um caso por classe, não cem.

A segunda técnica corrige o ponto cego da primeira. Os bugs não se distribuem de modo uniforme: concentram-se nas bordas. Um programador escreve < onde deveria escrever <=, e o erro só aparece bem no limite. Por isso a análise de valores limite testa os extremos de cada classe e seus vizinhos imediatos. Para o intervalo 0 a 120, você não testa um número qualquer do meio: testa -1, 0 e 1 na borda inferior, e 119, 120 e 121 na superior. É ali que o software quebra.

03 · a lógicaTabelas de decisão para regras de negócio

Classes e limites funcionam às mil maravilhas quando cada entrada é testada por conta própria. Mas muito software não é assim: a saída depende de combinações de condições. "Se o cliente é premium e o carrinho passa de 50 euros e é a sua primeira compra, aplica desconto dobrado." Aí não basta testar cada condição isolada, porque o bug mora na interação entre elas.

A técnica correta é a tabela de decisão. Você lista as condições de entrada em cima, as ações ou resultados embaixo, e cada coluna é uma combinação possível com seu resultado esperado. Com três condições binárias você tem oito combinações; a tabela obriga você a olhar todas e a decidir, com a especificação na mão, o que deveria acontecer em cada uma. O revelador é o que ocorre quase sempre: ao preencher a tabela você descobre combinações que ninguém havia pensado e para as quais a especificação nada diz. Essa lacuna é um bug antes de escrever um único teste.

Quando a explosão de combinações é enorme, você não testa todas. Aí entram variantes como o teste por pares, que reduz centenas de combinações a algumas dezenas sem perder quase nada de cobertura de defeitos. O princípio é o mesmo de todo o artigo: não cobrir cada combinação, mas cobrir o risco com o mínimo de casos.

A tabela não só gera casos: mostra as regras que ninguém escreveu.

04 · o critérioQuando usar cada técnica e como documentá-la

Nenhuma técnica é a boa em abstrato; cada uma responde a uma forma de risco. O guia prático é este: se o campo tem intervalos ou conjuntos de valores, use classes de equivalência com valores limite. Se o resultado depende da combinação de várias condições, use tabela de decisão. Se o comportamento depende da ordem das coisas ou do estado do sistema, falta uma quarta técnica, a transição de estados, que merece o seu próprio artigo.

E há uma regra que envolve todas elas: um caso de teste sem resultado esperado definido de antemão não é um caso de teste, é uma exploração. A potência dessas técnicas é que o resultado esperado sai da especificação, não de olhar o que o sistema fez e dar por bom. Sem esse oráculo prévio, você não está testando: está confirmando o seu próprio viés.

Tudo isso se conecta a algo maior do que a caça aos bugs. A norma ISO/IEC 25010 define a qualidade do software em atributos como a correção funcional, e as técnicas de projeto de casos são, literalmente, a maneira de evidenciar que esse atributo se cumpre. Não é burocracia: é a diferença entre afirmar "isto funciona" e poder mostrar com quais casos, escolhidos com qual critério, você comprovou. O ISTQB coloca essas técnicas no centro da formação de um testador precisamente por isso: são a ponte entre a intuição e o método.

Então, da próxima vez que sentir a vertigem dos infinitos testes possíveis, não comece a digitar entradas ao acaso. Pergunte primeiro: isto são intervalos, combinações ou estados? A resposta diz qual técnica tirar da caixa, e de repente o problema deixa de ser infinito e passa a ser uma lista curta, ordenada e, acima de tudo, repetível.