Depois que uma equipe publica uma correção para um defeito de cálculo de pagamento, ela reexecuta os testes que falharam anteriormente (isso é reteste) e então executa a suíte de regressão completa cobrindo o restante do fluxo de checkout. O teste de regressão verifica que áreas não alteradas — como a lógica de desconto e o cálculo do custo de envio — continuam se comportando corretamente após a modificação. Na integração contínua, os testes de regressão normalmente são executados automaticamente a cada mudança de código.
Qual é a diferença entre teste de regressão e reteste? O reteste executa os casos de teste específicos que falharam da última vez para verificar se a correção funcionou. O teste de regressão executa testes sobre funcionalidade já testada e não alterada, para garantir que a mudança não introduziu novos defeitos. Ambos são necessários após uma correção.
Quando o teste de regressão é realizado? Sempre que o software ou seu ambiente muda: novas funcionalidades, correções de bugs, mudanças de configuração ou atualizações de infraestrutura. Quanto maior a mudança, mais importante é a cobertura de regressão.
Quanto teste de regressão é suficiente? O suficiente para cobrir o risco da mudança. As equipes geralmente começam com uma passada de teste de fumaça nos caminhos críticos e depois expandem com base no impacto da mudança e na automação de teste disponível.
O teste de regressão é um nível de teste? É um tipo de teste, não um nível — os testes de regressão podem ser executados em qualquer nível, do teste de componente ao teste de sistema, e frequentemente aparecem em várias fases.
