Esses quatro termos são frequentemente confundidos, gerando expectativas diferentes de escopo e discussões sobre palavras. Na prática, combinar um significado compartilhado na equipe importa mais do que debater a definição correta do livro.
Teste smoke
O teste smoke estabelece rapidamente se o sistema está operacional de forma geral e apto para continuar os testes ou o uso. Geralmente inclui os caminhos felizes mais críticos: inicialização, login, navegação básica, criação de uma entidade principal e disponibilidade essencial da API.
Teste sanity
O teste sanity é uma verificação restrita e direcionada de uma mudança específica ou área problemática. Após uma pequena alteração no cálculo de desconto, por exemplo, a equipe verifica os cenários relacionados e as áreas próximas, em vez do produto inteiro.
Teste de regressão
O teste de regressão verifica novamente funcionalidades existentes para confirmar que novas mudanças não quebraram o comportamento anterior. Geralmente é mais amplo do que smoke ou sanity e segue os riscos conhecidos do produto.
Reteste
O reteste, também chamado de teste de confirmação, verifica um defeito específico corrigido: o bug foi resolvido no cenário em que foi encontrado? Ele não substitui o teste de regressão porque não estabelece o que mais pode ter sido afetado.
Distinções práticas
- →Smoke: este build está apto para continuar os testes?
- →Sanity: a área específica continua se comportando como esperado após uma mudança local?
- →Reteste: este defeito específico foi corrigido?
- →Regressão: as mudanças afetaram outras funcionalidades?
Orientação prática
- →Documente um vocabulário compartilhado da equipe para que todos entendam o escopo de forma consistente.
- →Crie testes de regressão em torno do risco, em vez de uma seleção arbitrária de casos antigos.
- →Não trate o reteste por si só como evidência de liberação suficiente quando a alteração afetar áreas dependentes.
Escolha pelo objetivo: uma versão com correção de desconto
Requisito fictício DISC-1: aplique um desconto de 10% quando o subtotal das mercadorias for de pelo menos 10000 centavos. Um defeito relatado usava > em vez de >=, portanto um carrinho de 10000 centavos não recebia desconto. Todos os valores abaixo produzem resultados em centavos inteiros; outros valores precisam de uma regra explícita de arredondamento. A versão altera esse comparador em uma função compartilhada de cálculo do total.
Verificação Objetivo Gatilho Escopo Exemplo
Smoke O build pode ser usado para continuar os testes? Nova implantação Conjunto pequeno nas funções críticas Aplicação abre, login funciona, catálogo carrega, checkout abre
Sanity (convenção da equipe aqui) A área alterada se comporta de forma plausível? Correção pequena e direcionada Área próxima à mudança Subtotais 9900 / 10000 / 10100 resultam em 9900 / 9000 / 9090
Reteste / confirmação O defeito relatado foi corrigido? Correção de um problema conhecido Reprodução original e resultado esperado O mesmo carrinho de 10000 centavos agora retorna 9000
Regressão A mudança prejudicou o comportamento existente? Mudança com possível impacto Funções relacionadas e dependentes selecionadas por risco Pedidos salvos, faturas e cálculos de reembolso ainda atendem às expectativas aprovadasUm lançamento, quatro perguntas separadas
Execute primeiro o teste smoke do ambiente. Se o checkout não abrir, registre um bloqueio; uma implantação com falha não prova que a correção do comparador esteja errada. Depois, repita a configuração exata do defeito, a conta, a moeda e a entrada no novo build: 10000 deve produzir 9000. Isso é confirmação. Em seguida, teste os valores próximos 9900 e 10100 com o conjunto focado; a equipe pode chamá-lo de teste sanity.
Para regressão, inspecione os chamadores do cálculo compartilhado antes de selecionar os testes. Inclua totais de pedidos armazenados, totais de faturas e qualquer caminho de reembolso que realmente chame a função. Reconcilie cada um com um resultado esperado acordado e salvo de acordo com suas próprias regras; não presuma que o reembolso seja automaticamente 90% ou que cada consumidor compartilhe DISC-1. Adicione uma cesta sem desconto anteriormente válida como controle. A amplitude segue evidências de dependência e risco de negócios, não uma regra fixa de contagem de testes.
Uma pequena demonstração executável
Salve como release_check_selection.py e execute python3 release_check_selection.py. Saída esperada: Known defect reproduced; confirmation and three focused checks passed. Este script demonstra apenas a aritmética e a lógica de seleção: não executa um teste smoke da aplicação nem a suíte de regressão das funcionalidades dependentes.
def old_total(cents):
return cents * 9 // 10 if cents > 10000 else cents
def fixed_total(cents):
return cents * 9 // 10 if cents >= 10000 else cents
# Values below produce whole-cent results; no rounding rule is inferred.
assert old_total(10000) == 10000
assert fixed_total(10000) == 9000
for cents, expected in [(9900, 9900), (10000, 9000), (10100, 9090)]:
assert fixed_total(cents) == expected
print("Known defect reproduced; confirmation and three focused checks passed")Registre o limite da evidência
Um caso pode pertencer a mais de um conjunto: a verificação de 10000 centavos é evidência de confirmação do problema e uma verificação útil para regressões futuras. Não conte a execução duplicada como cobertura comportamental adicional. Registre build, objetivo, resultado real e risco não coberto para que o leitor saiba o que “aprovado” significa.
Sanity tem significados diferentes entre equipes e às vezes é usado como sinônimo de smoke. Defina seu escopo localmente, em vez de tratar esta tabela como uma taxonomia obrigatória. Confirmação e regressão respondem a perguntas diferentes; corrigir a reprodução original não estabelece que o comportamento ao redor permaneça inalterado.
Exercício: o reteste exato de 10000 centavos passou, mas as faturas ainda mostram 10000 depois de o checkout salvar 9000. É possível declarar a versão sem problemas? Não. O defeito original pode estar corrigido enquanto uma regressão de funcionalidade dependente falha. Registre ambos os resultados e investigue a inconsistência, em vez de transformar um reteste aprovado em um veredito de lançamento.
Continuar aprendendo
Construa uma estratégia de regressão em torno do risco
Coletar evidências de liberação