Depois de uma equipa publicar uma correção para um defeito no cálculo do pagamento, volta a executar os testes que falharam anteriormente (isto é reteste) e executa depois a suíte de regressão completa que cobre o resto do fluxo de finalização da compra. O teste de regressão verifica que as áreas inalteradas — como a lógica de descontos e o cálculo dos custos de envio — continuam a comportar-se corretamente após a modificação. Em integração contínua, os testes de regressão são normalmente executados automaticamente em cada alteração 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 inalterada para garantir que a alteração não introduziu novos defeitos. Ambos são necessários após uma correção.
Quando é realizado o teste de regressão? Sempre que o software ou o seu ambiente muda: novas funcionalidades, correções de bugs, alterações de configuração ou atualizações de infraestrutura. Quanto maior a alteração, mais importante é a cobertura de regressão.
Quanto teste de regressão é suficiente? O suficiente para cobrir o risco da alteração. As equipas começam frequentemente com uma passagem de teste de fumo sobre os caminhos críticos e depois expandem com base no impacto da alteração e na automação de testes 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 componentes ao teste de sistema, e aparecem frequentemente em várias fases.
