O que são testes de regressão? Verificar que a correção não partiu outra coisa

Testar a regressão é verificar que aquilo que funcionava continua a funcionar, depois de uma alteração. Não a alteração em si - essa testa-se enquanto se escreve - mas tudo o que está à volta, que ninguém tocou e que ninguém esperava que fosse afetado.

O nome diz tudo. Uma regressão é um passo atrás: uma funcionalidade que funcionava na versão anterior e não funciona nesta. Estes testes existem porque o software está ligado por caminhos que ninguém guarda na cabeça, e o código de desconto que alguém arranjou na terça-feira partilha uma função com o cálculo do imposto que ninguém olha desde março.

Porque é o trabalho de alguém

Cada alteração tem um raio de impacto maior do que o seu diff. Uma função partilhada, uma coluna de base de dados lida em seis sítios, uma regra CSS que afinal sustentava uma página que o autor nunca tinha aberto.

A falha que isto evita é concreta e cara: uma versão que corrige um erro reportado e introduz dois que ninguém reportou. Esses custam muito mais do que o original, porque ninguém anda à procura deles. O erro reportado tinha alguém à espera da correção; os novos são descobertos pelos clientes, dias depois, sem qualquer ideia do que mudou.

O que voltar a testar de facto

Não consegue voltar a testar tudo a cada alteração, e as equipas que tentam acabam com uma suite tão lenta que é saltada. Testar a regressão é um problema de seleção, e a seleção faz-se pelo risco.

Vale a pena voltar a testar em quase qualquer alteração:

• Os caminhos que dão dinheiro. Registo, autenticação, checkout, pagamento. Tudo o resto pode esperar por segunda-feira; estes não.
• O que a alteração toca de facto, mais tudo o que partilha com ela uma função, uma tabela ou um template.
• Aquilo que já se partiu antes. Um defeito que voltou uma vez volta outra, e um erro que regrediu é o melhor argumento para um teste permanente.
• As integrações que não controla. Tudo o que chega a outro serviço falha por motivos que nada têm a ver com a sua versão.

Não vale a pena de cada vez: ecrãs de definições pouco usados, ferramentas de administração com dois utilizadores, tudo aquilo cuja falha alguém notaria e reportaria sem dano.

Onde acaba o smoke test e começa isto

São feitos em momentos diferentes e respondem a perguntas diferentes.

Smoke test

Vale a pena testar esta build? Cinco verificações, minutos, corre primeiro, em cada build

Teste de regressão

Alguma coisa que funcionava deixou de funcionar? Centenas de verificações, mais demorado, corre depois de a build se ter provado

Correr uma suite de regressão contra uma build que não consegue autenticar um utilizador gasta uma hora a prová-lo de quatrocentas maneiras. O smoke test vem primeiro exatamente por isso.

À mão ou automatizado

A automatização é a resposta óbvia e a incompleta.

Automatize o que é estável, valioso e maçador: os caminhos do dinheiro, os contratos da API, os cálculos com entradas conhecidas e respostas conhecidas. Esses valem a pena escrever uma vez e correr para sempre, e são os testes que apanham uma regressão às três da manhã sem ninguém a olhar.

Guarde uma pessoa para aquilo que um script não consegue julgar. Se o layout está errado e não apenas diferente. Se uma mensagem de erro faz sentido. Se o fluxo ainda dá a sensação de funcionar. Uma comparação de capturas dir-lhe-á que onze píxeis se moveram; não lhe dirá que o botão ficou abaixo da dobra no portátil mais comum da sua base de utilizadores.

A maioria das equipas acaba com uma suite automatizada para os caminhos que não podem partir e uma passagem manual curta pelas áreas que a versão tocou.

Como uma suite se estraga

De três maneiras, todas comuns, e cada uma acaba com a suite ignorada.

Fica lenta. Uma suite que demora noventa minutos corre à noite em vez de a cada alteração, e sobre uma regressão encontrada na manhã seguinte já se construiu.

Fica instável. Um teste que falha uma vez em cada dez ensina toda a gente a relançá-lo, e o hábito de relançar é indistinguível de não ter o teste. Uma coisa verdadeiramente partida esconde-se no ruído das que são apenas pouco fiáveis.

Só cresce. Acrescentam-se testes por cada defeito e não se retira nenhum, até metade da suite cobrir comportamento que o produto já não tem. Apagar testes faz parte de os manter.

Quando aparece uma regressão

Um teste de regressão falhado é um relatório de erro por escrever, e começa com mais informação do que a maioria dos relatórios alguma vez recebe: sabe que funcionava antes, e muitas vezes em que versão exata deixou de funcionar.

Diga isso. “Funcionava em 4.2.0, falha em 4.3.0” transforma uma investigação num diff. É a frase mais útil de um relatório de regressão e a que mais vezes fica de fora, porque quem o escreve assume que toda a gente sabe.

Para uma regressão com que alguém tropeça à mão, em vez de uma que a suite apanhou, o contexto é o que costuma faltar.

O resto do que um bom relatório precisa está no guia do relatório de erro, e o seu modelo tem uma linha para a versão em que funcionava.

A versão curta

Testar a regressão pergunta se a alteração que fez partiu alguma que não fez. Escolha o que voltar a testar pelo risco e não pela ambição, ponha os caminhos do dinheiro sob automatização, guarde uma pessoa para os juízos que um script não consegue fazer, e apague testes com a mesma vontade com que os acrescenta. Quando encontrar uma, diga em que versão funcionava pela última vez.