Testes de regressão: que consertar A não quebre B

Um teste de regressão é um teste que você executa de novo depois de uma mudança para confirmar que aquilo que já funcionava continua funcionando. Esse é o sentido inteiro do nome: a regressão é quando o software "retrocede", quando uma funcionalidade que antes estava correta volta a falhar por causa de uma modificação recente. O teste de regressão existe para pegar esse retrocesso antes que ele chegue ao usuário.

A cena é clássica. Você conserta o bug A, entrega, e três dias depois alguém relata que o fluxo B, que ninguém tocou, parou de funcionar. Não é azar: A e B compartilhavam algo (uma função, um dado, uma suposição) e o seu conserto tirou o chão de debaixo de B. A regressão é a disciplina de nunca confiar na frase "isso eu não mexi".

01 · o que éRegressão: quando o passado volta a quebrar

O padrão internacional de vocabulário de testes define isso sem rodeios: o teste de regressão é aquele executado sobre um componente ou sistema já testado, depois de uma modificação, para verificar que nenhum defeito foi introduzido e que nenhum defeito anterior ficou à mostra nas partes não modificadas [1]. Repare na nuance: você não busca testar o novo, você busca defender o antigo.

Um defeito de regressão quase nunca aparece onde você trabalhou. Ele surge ao lado, num código que você nem abriu. A razão é que o software está cheio de dependências invisíveis: uma função que outras cinco chamam, uma variável global, um formato de data, uma ordem de resultados que alguém supôs constante. Você muda uma e as outras cinco ficam sabendo tarde, em produção.

A regressão não testa o que você fez. Ela protege o que já funcionava daquilo que você acabou de fazer.

Por isso a regressão difere dos demais testes na intenção. Um teste novo pergunta "isto que acabei de construir faz o que deve?". Um teste de regressão pergunta "isto que já existia continua fazendo o que fazia?". O primeiro valida; o segundo vigia. E como o produto cresce, a lista de coisas a vigiar só fica mais longa.

02 · por que cresceA suíte engorda no ritmo do produto

Aqui está a armadilha que pega toda equipe jovem de surpresa. Cada funcionalidade nova que você entrega se torna, a partir daquele momento, algo que precisa continuar sendo protegido em cada release. A suíte de regressão não é uma lista fixa: é a soma de tudo o que um dia funcionou e que você não quer perder. Ela cresce com o produto, versão após versão.

No começo dá para fazer na mão. Dez telas, vinte fluxos, um testador percorre tudo numa manhã. Mas o produto não fica em dez telas. Com dois anos você tem centenas de fluxos, e "percorrer todos na mão antes de cada entrega" se torna impossível: levaria dias, ninguém faz por completo, e os defeitos de regressão começam a se infiltrar justamente pelos cantos que deixaram de ser revisados por falta de tempo.

Esse crescimento explica por que a regressão é a candidata número um à automação. Um teste de regressão é, por definição, algo que você já sabe que deveria passar e que vai executar muitas vezes sem mudanças. É repetitivo, previsível e chato: exatamente o tipo de trabalho que uma máquina faz melhor do que uma pessoa. Automatizar o novo e o exploratório é difícil; automatizar o que já está estável e só precisa ser revisado uma e outra vez é onde a automação rende de verdade.

A regressão manual escala com a equipe. A regressão automatizada escala com o produto. Só uma das duas vence essa corrida.

03 · o que reexecutarVocê não pode rodar tudo: é preciso priorizar

Mesmo que você automatize, chega um ponto em que a suíte completa demora demais para rodar a cada pequena mudança. Então surge a pergunta central da regressão madura: de tudo o que poderia ser reexecutado, o que eu reexecuto agora? Rodar tudo é sempre o mais seguro, mas também o mais lento, e a lentidão tem um custo: se a regressão leva horas, as pessoas param de rodá-la.

A resposta se apoia em duas ideias. A primeira é a seleção por impacto: você prioriza os testes que cobrem as áreas que a sua mudança pode ter afetado, mais as áreas de maior risco (o que os clientes mais usam, o que mais movimenta dinheiro, o que mais vezes quebrou antes). Nem todos os testes valem o mesmo; um que protege o pagamento pesa mais do que um que protege uma tela de ajuda.

A segunda ideia é a higiene da suíte. Uma regressão que cresce sem poda se enche de testes frágeis (que falham por motivos que não são bugs reais) e de testes duplicados. Os testes frágeis são perigosos porque ensinam a equipe a ignorar as falhas vermelhas, e um alarme ignorado não protege nada. Manter a suíte significa apagar o morto, consertar o instável e não deixar que ela engorde sem controle.

04 · onde viveA regressão se encaixa no pipeline de CI/CD

Tudo o que veio antes faz sentido quando a regressão deixa de ser um evento manual e passa a fazer parte do pipeline de integração e entrega contínua. A ideia da integração contínua é que cada mudança que um desenvolvedor sobe dispara automaticamente a construção e os testes do projeto, para detectar os problemas em minutos e não em semanas [2]. A regressão automatizada é o coração desse disparo.

O padrão prático costuma ser em camadas. A cada mudança roda uma regressão rápida e seletiva (os testes de maior risco e impacto, em poucos minutos). Uma vez por dia, ou antes de liberar, roda a suíte completa, mais lenta, que revisa todo o resto. Assim o desenvolvedor tem uma resposta veloz para seguir trabalhando, e o produto tem uma rede completa antes de chegar ao cliente.

Quando isso funciona, a regressão deixa de morar na cabeça de uma pessoa e passa a ser uma propriedade do sistema: toda vez que alguém propõe uma mudança, o pipeline responde "está tudo verde" ou "você quebrou isto", e faz isso sem que ninguém precise lembrar de revisar. Essa é a diferença entre torcer para que o conserto de A não quebre B, e saber disso antes de entregar.

Que a ideia fique firme: a regressão não é um tipo de teste raro nem avançado. É uma postura diante da mudança. Cada coisa que funciona hoje é algo que amanhã uma mudança inofensiva pode quebrar, e a única defesa razoável é ter uma rede que reverifique o de sempre, a cada vez, de forma automática e priorizada. O passado volta a quebrar o tempo todo. A regressão é o que avisa você quando isso acontece.