Testes de regressão (do inglês, regression testing) são testes realizados em um site, sistema ou aplicação antes do lançamento de uma nova funcionalidade ou correção, para certificar que nada além do esperado foi adicionado ao sistema.
Na área de qualidade de software, eles representam a segurança, estabilidade e confiança de um software. Eles atestam que, quando uma nova funcionalidade ou correção seja lançada, outras não sejam impactadas.
Além disso, eles podem antecipar erros, conhecidos como “bugs“, nas demais partes do sistema. Se bem escritos, podem até antecipar problemas de infraestrutura e performance.
Eles também trazem a confiança de colocar algum desenvolvimento no ambiente de produção com a garantia de que as funcionalidades principais permaneçam inalteradas.
Como eles funcionam?
Imagine uma rede social online. Agora pense que, ao lançar uma correção para ajustar a foto de perfil dos usuários, sem saber, um erro foi introduzido. Como o trecho de código alterado era responsável pelo controle geral das fotos, todas as fotos do seu perfil ficaram liberadas para todos os usuários da rede social. Isso poderia ser uma catástrofe, não?
É exatamente esse tipo de erro que os testes de regressão podem antecipar quando uma nova parte do sistema é disponibilizada.
Agora pense que, por causa desta correção, a performance do site ainda caiu 50%, uma vez que todas as imagens agora são carregadas ao acessar um perfil… E as noticias da falha, que além de impactar seriamente os usuários, mancham a imagem da sua empresa? E o tempo gasto para reverter esta falha antes que impacte mais pessoas?
É isto que os testes de regressão tentam evitar.
Ferramentas de teste de regressão
Existem inúmeras ferramentas para fazer este tipo de teste. O que manda é o que deve ser testado.
Existem ferramentas para testar o backend, o frontend, a camada de negócios, a performance, etc.
Cito aqui algumas gratuitas, que apesar do trabalho para implementar, são bem maleáveis no sentido de controle dos testes:
- SoapUI
- Postman
- Selenium
- Playwright
- Cypress
- WebdriverIO
- PhantomCSS
- Applitools
Acredito que todas elas até podem ser implementadas junto com o seu processo de entrega, ou seja, automatizadas, mas com um certo esforço.
Lembro aqui que, antes disso tudo, é importante ter testes unitários (os famosos unit tests) bem desenhados, a serem executados com sucesso antes de se pensar em testes de regressão.
Desafios dos testes de regressão
Manter estes tipos de testes não é uma tarefa fácil, uma vez que se deve sincronizar alterações de layout, negócio e código minimamente. Assim, eles devem ser constantemente atualizados e podem crescer rapidamente.
Outro ponto importante é manter uma boa cobertura do sistema, pois uma alteração em uma funcionalidade principal pode facilmente impactar paginas ou telas menores que raramente são acessadas.
A outra questão já foi dita, que é automatizar isso tudo em um processo de entrega (CD/ CI) que nem sempre é tarefa uma fácil tecnicamente, além de aumentar o tempo gasto na entrega.
Testes de regressão costumam tomar bastante tempo, mesmo que automatizados, dependendo do alcance da cobertura, da performance do sistema e do computador que realiza os testes, das interações e checagens.
Benefícios de ter testes de regressão
Além dos benefícios já citados, que são o de antecipar erros, passar mais segurança no momento de disponibilizar uma nova versão em produção e aumentar a qualidade das entregas, o que evita ter de desfazer algum deploy mal feito, ele também pode trazer benefícios ao ciclo de desenvolvimento.
Tê-los de forma informatizada é outra grande vantagem. Imagine que, a cada novo ajuste no sistema, uma pessoa deve acessar todas as paginas, telas e funcionalidades dele para ver se tudo ainda funciona corretamente?
Além de ter de conhecer bem o sistema, todas as suas páginas e regras de negócio, ainda tem de verificar se e-mails foram enviados ou rotinas foram feitas. Isto pode envolver muitas pessoas, tempo e dinheiro.
Se feitos de forma manual, ainda podem estar propenso a erros, como vimos, que podem até impactar a imagem da empresa.
Conclusão
Do ponto de vista de um time de desenvolvimento, tente incluir os testes como itens da sprint, se falando de agile, e unit tests a nível de código. Um bom processo de code review também ajuda muito na qualidade do software.
Já falando do negócio, é imprescindível não ter novos erros quando se tenta corrigir alguma funcionalidade do sistema. Simples assim.
Abrace esta vertente no seu mindset, pois vale a pena.