GitHub

A pior categoria de bug não é o que você introduz numa funcionalidade nova. É o que você ressuscita numa funcionalidade antiga, que funcionava perfeitamente até alguém mexer em outra coisa.

É uma cena familiar. O time corrige um problema, faz o deploy, comemora, e três dias depois descobre que aquela correção quebrou silenciosamente um fluxo que ninguém pensou em conferir. O cliente encontra primeiro. A confiança no sistema, e no time, leva um arranhão.

Esse fenômeno tem nome: regressão. É o sistema andando para trás. E o conjunto de práticas que existe para evitá-lo é o teste de regressão, provavelmente o tipo de teste mais subestimado e mais valioso de todos.

O que é teste de regressão

Teste de regressão é a reexecução de testes sobre funcionalidades que já existiam, para garantir que uma mudança recente não quebrou nada que já funcionava. A palavra-chave é "já existiam". Ele não verifica o que você acabou de construir; verifica tudo o que você poderia ter quebrado sem querer ao construí-lo.

A premissa é uma verdade incômoda do software: todo sistema é uma teia de dependências, muitas delas invisíveis. Mexer num ponto pode afetar outro a quilômetros de distância no código. Ninguém consegue, só pela cabeça, prever todas as consequências de uma mudança. Teste de regressão é a rede que pega o que a cabeça não previu.

Por que toda mudança é um risco

Software não é estático. Ele muda o tempo todo, correções, funcionalidades, atualizações de bibliotecas, ajustes de configuração. E cada mudança, por menor que pareça, carrega risco de regressão.

O perigoso é que o tamanho da mudança não prediz o tamanho do estrago. Uma alteração de uma linha pode derrubar um fluxo crítico se essa linha estiver num ponto compartilhado por muitas partes do sistema. Já vi correções triviais causarem incidentes maiores que reescritas inteiras.

Esse é o paradoxo da manutenção: quanto mais um sistema cresce e amadurece, mais valioso ele fica, e mais arriscado fica mudá-lo, porque há mais coisa que pode quebrar. Sem rede de regressão, o time chega a um ponto em que tem medo de tocar no próprio produto. O sistema "congela" não por estar pronto, mas por ser perigoso demais mexer.

Por que regressão pede automação

É possível fazer regressão manualmente, reexecutar à mão os fluxos principais após cada mudança. Funciona quando o sistema é pequeno. Deixa de funcionar rápido.

O problema é de escala e de repetição. Regressão precisa ser feita a cada mudança, sobre um conjunto que só cresce. Fazer isso na mão, repetidamente, é caro, lento e, pior, sujeito a cansaço humano. O testador manual, na centésima vez que confere o mesmo fluxo, presta menos atenção. É natural.

Por isso regressão é o caso de uso por excelência da automação. Um teste automatizado não se cansa, não pula etapas e roda em segundos o que levaria horas na mão. É exatamente o tipo de verificação repetitiva e objetiva que a máquina faz melhor que a pessoa. A suíte de regressão automatizada é o que permite mudar o sistema com frequência sem medo.

O que entra na suíte de regressão

Nem tudo precisa estar na suíte. Tentar cobrir cada caminho possível gera uma suíte gigante, lenta e cara de manter, que o time acaba ignorando.

A regra prática é priorizar por risco e por frequência. Entram os fluxos críticos para o negócio, aqueles cuja quebra causa prejuízo real ou perda de confiança. Entram também as áreas que historicamente já quebraram: todo bug corrigido deveria virar um teste de regressão, para garantir que ele não volte. Esse é um dos melhores hábitos que um time pode adotar.

O que costuma ficar de fora, ou em prioridade menor, são funcionalidades periféricas, raramente usadas, de baixo impacto. Cobertura total não é o objetivo; proteção do que importa é.

Os erros que tornam a regressão inútil

O primeiro erro é deixar a suíte apodrecer. Testes de regressão refletem o comportamento esperado do sistema. Quando o comportamento muda legitimamente e os testes não são atualizados, eles passam a falhar por estarem desatualizados, não por bug real. O time aprende a ignorar as falhas, e a rede deixa de pegar qualquer coisa.

O segundo é tolerar testes intermitentes. Um teste de regressão que às vezes passa e às vezes falha sem motivo é veneno: ele dilui a credibilidade de toda a suíte. Quando o vermelho deixa de significar "algo quebrou", a regressão perdeu a função.

O terceiro é rodar regressão tarde demais. Se a suíte só roda na véspera do release, os problemas se acumulam e ficam caros de rastrear. O ideal é rodar a cada mudança, na esteira de integração, para que a quebra seja detectada perto da causa, quando ainda é barata de corrigir.

Regressão é o que dá liberdade para evoluir

Há uma leitura equivocada de que teste de regressão é uma trava, uma burocracia que atrasa a entrega. É o oposto. Uma boa suíte de regressão é o que dá liberdade para o time entregar rápido.

Sem ela, cada mudança exige cautela, conferência manual, medo. Com ela, o desenvolvedor muda o código, roda a suíte e, em minutos, sabe se quebrou algo. Essa confiança é o que permite manter o ritmo de entrega à medida que o sistema cresce. Regressão não freia a velocidade; é o que torna a velocidade sustentável.

Em sistemas que sustentam serviços críticos, públicos ou privados, isso é ainda mais decisivo. A capacidade de evoluir um sistema essencial sem o medo de derrubar o que já funciona é, no fundo, uma capacidade de governança. Teste de regressão é uma das ferramentas que a tornam possível.

No fim, todo software estável é um sistema que alguém teve coragem de não deixar parado. Regressão é o que torna essa coragem responsável em vez de imprudente.

Se o seu time já evita tocar em partes do sistema por medo de quebrar algo, esse medo é um sintoma de falta de rede de regressão, e é endereçável. Tenho outros artigos no blog sobre qualidade, automação e manutenção de software que conversam com este.