Introdução

Os sete princípios vêm do syllabus CTFL da ISTQB. São generalizações empíricas sobre o que teste consegue e não consegue fazer, usadas para calibrar expectativa e esforço. A numeração abaixo segue o CTFL 4.0.

Como agrupar

• 1, 2 e 7: limites do que teste pode garantir.
• 3 e 4: onde e quando alocar esforço.
• 5 e 6: como manter a abordagem eficaz ao longo do tempo e entre projetos.

1. Teste mostra a presença de defeitos, não a ausência

Teste reduz a probabilidade de defeitos não descobertos, mas não prova correção. A formulação clássica é de Dijkstra. Passar em 1.000 casos não garante o comportamento no 1.001º.

Exemplo:

A suíte de cálculo de juros e multa de boleto passa com 200 casos e quebra num vencimento em 29/02.

Implicação:

Reportar "nenhum defeito encontrado com esta cobertura e estes riscos", nunca "sem bugs".

2. Teste exaustivo é impossível

Testar todas as combinações de entradas, estados e pré-condições é inviável fora de casos triviais. Por isso existem técnicas de redução (partição de equivalência, análise de valor limite, tabela de decisão, pairwise) e priorização por risco.

Exemplo:

Um formulário com 10 campos e 5 valores relevantes por campo gera 5¹⁰ = 9.765.625 combinações.

Implicação:

Apergunta deixa de ser "testei tudo?" e passa a ser "testei o que tem mais risco, com o menor número de casos que cobre as classes de comportamento?".

3. Teste antecipado economiza tempo e dinheiro

Defeito achado em requisito ou design custa menos que o achado em produção. Isso inclui teste estático (revisão de requisitos e de código, análise estática), que encontra defeitos sem executar nada: o "shift left". Os multiplicadores clássicos (10x, 100x) vêm de dados antigos e são contestados, mas a direção do argumento se mantém.

Exemplo:

Uma ambiguidade na regra de arredondamento, apontada na revisão do requisito, vira uma conversa. Essa mesma descoberta depois do fechamento do mês em produção, vira correção, reprocessamento e acerto de dados.

4. Defeitos se agrupam

Poucos módulos concentram a maior parte dos defeitos. Costuma-se descrever isso pelo princípio de Pareto (80/20 como heurística, não como lei).

Exemplo:

3 de 40 módulos respondem por mais da metade dos bugs de produção.

Implicação:

Usar histórico de defeitos, churn de código e complexidade para direcionar o esforço (teste baseado em risco). Cuidado com o viés: um módulo pode parecer problemático só por ser o mais testado.

5. Os testes se desgastam (versão 3.1: "paradoxo do pesticida")

Repetir os mesmos testes deixa de encontrar defeitos novos, porque os que eles alcançavam já foram corrigidos. Isso não invalida regressão automatizada, cujo objetivo é detectar quebra, não achar defeito novo. O problema é depender só dela.

Exemplo:

30 cenários de checkout verdes há dois anos, sempre com o mesmo usuário e o mesmo cartão. Nenhum exercita cupom + frete grátis + estorno parcial.

Implicação:

Revisar e variar casos e dados periodicamente, complementar com teste exploratório e usar mutation testing para medir se a suíte detecta falhas de fato.

6. Teste depende do contexto

Não existe abordagem única. O que, quanto e como testar depende de risco, domínio, ciclo de vida, regulação e tecnologia.

Em aviônica (DO-178C, nível A) exige-se cobertura MC/DC e rastreabilidade formal, enquanto num MVP isso é desperdício. E-commerce com pico sazonal prioriza carga e performance. Sistema sob obrigação regulatória prioriza conformidade e rastreabilidade das regras.

7. A ausência de defeitos é uma falácia (versão 3.1: "falácia da ausência de erros")

Achar e corrigir todos os defeitos não adianta se o sistema não atende à necessidade do usuário. É a distinção entre verificação (construímos conforme a especificação?) e validação (construímos a coisa certa?).

Exemplo:

O sistema segue a especificação sem desvio algum, mas ela descrevia um fluxo que ninguém usa. Zero bugs, zero valor.

Implicação:

Incluir validação com usuário e negócio (teste de aceite, protótipo, feedback em produção), não só verificação contra requisito.