Glossário · Fundamentos de testes
Teste de regressão
Em inglês: Regression testing
Também chamado de: testes de regressão, regression test, suíte de regressão, regressão
Definição
Reexecutar testes existentes após uma mudança para confirmar que o comportamento que já funcionava continua funcionando e que a correção ou feature não quebrou mais nada.
O teste de regressão (regression testing) verifica se uma mudança não quebrou algo que funcionava. Uma “regressão” é uma funcionalidade que funcionava em um build anterior e deixou de funcionar. Você a encontra reexecutando os testes do comportamento existente depois de cada correção de bug, nova feature, refatoração, atualização de dependência ou mudança de configuração.
Exemplo
Um time adiciona a opção “pagar com vale-presente” no checkout. A nova feature ganha seus próprios testes. O teste de regressão faz uma pergunta diferente: pagamentos com cartão, cupons de desconto, cálculo de impostos e e-mails de pedido continuam se comportando exatamente como antes? Uma mudança no módulo compartilhado de cálculo de preços poderia facilmente quebrar qualquer um deles sem tocar no novo fluxo.
Escolhendo o que rodar
Rodar todos os testes a cada commit é a estratégia mais simples e, com uma suíte automatizada rápida, muitas vezes é a correta. Quando a suíte completa é lenta demais ou parcialmente manual, os times selecionam:
- Por risco. Fluxos críticos para o negócio (cadastro, pagamento, exportação de dados) sempre rodam.
- Por impacto. Áreas que compartilham código, dados ou serviços com a mudança.
- Por histórico. Módulos que já regrediram antes tendem a regredir de novo.
Uma divisão comum é um subconjunto rápido de regressão a cada pull request e a suíte completa à noite ou antes de um release.
Por que é a primeira coisa que os times automatizam
Testes de regressão executam os mesmos passos contra os mesmos resultados esperados repetidas vezes, que é exatamente aquilo em que a automação é boa. A regressão manual cresce a cada release, enquanto o tempo disponível não cresce, então ela é a primeira a ser cortada. Uma suíte de regressão automatizada no CI transforma o “quebramos alguma coisa?” de uma semana de verificação manual em um resultado de pipeline.
Erros comuns
- Tratar a suíte como algo em que só se adiciona. Testes obsoletos e duplicados deixam toda execução mais lenta. Revise e faça a poda.
- Tolerar testes flaky. Se as falhas são reexecutadas rotineiramente até ficarem verdes, as regressões reais também somem nas reexecuções.
- Testar só pela UI. A maior parte da cobertura de regressão é mais barata e mais estável nos níveis de unidade e de API.