Testes de regressão, você está fazendo certo?

Em meu primeiro post no Nerds-On falarei sobre Testes de Regressão que é um tipo de teste de software. Dentre todos os tipos existentes eu o considero um dos mais importantes, acho que por isso venho percebendo que ele não está sendo utilizado adequadamente.

Em uma definição livre, entendo que os testes de regressão são executados para garantir que uma funcionalidade ou parte do software já testado, continue funcionando após o mesmo sofrer alguma implementação ou manutenção.
É neste ponto que o teste de regressão se mostra muito importante para a garantia da qualidade do software entregue, pois poderemos evitar que uma funcionalidade que o cliente já utiliza não deixe de funcionar uma vez que o software sofra uma atualização de versão, evitando transtornos e desgastes junto ao cliente.

Outra definição para testes de regressão retirada do glossário de termos do ISTQB diz o seguinte:

Teste realizado em um programa previamente testado após alguma modificação feita e com a finalidade de assegurar que defeitos não tenham sido introduzidos ou mascarados nas áreas não alteradas do software como resultado da referida modificação. Este teste é realizado quando o software ou seu ambiente é alterado.

Agora surgem algumas perguntas a você leitor do blog, a sua equipe de desenvolvimento está executando testes de regressão? Você está fazendo certo?

Acredito que a resposta seja não.
Quero muito estar errado, mas percebo que muitas equipes apresentam a seus líderes o planejamento dos testes utilizando uma abordagem simples dos testes de regressão, onde se re-executa todos os casos de testes já elaborados para as funcionalidades do software, ou seja, é planejado o reteste de tudo. Essa abordagem não está errada, só que apresenta dois grandes problemas, custa caro e consome muito tempo. Se coloque no lugar do cliente e me diga se você não preferiria que o software fosse entregue mais rápido, com baixo custo e qualidade.

Para ajuda-los irei apresentar alguns dicas para a identificação do que deverá ou não ser planejado e testado na etapa de testes de regressão.

Rastreabilidade
Manter mapeada a rastreabilidade do software permitirá facilmente identificar quais as funcionalidades podem ser afetadas por uma mudança no software. Mudanças no software podem incluir novas funcionalidades ou alterar funcionalidades existentes em função de alguma necessidade do cliente.
Por exemplo, um software de venda de mercadorias, se alterar o cálculo do imposto do produto, verificando a rastreabilidade identificaremos que essa alteração de cálculo poderá impactar nas funcionalidades de emissão de nota e cupom fiscal, portando estas funcionalidades devem ter os seus testes de regressão planejados e executados.

Rotinas críticas
Identificar junto ao cliente quais são as rotinas mais utilizadas por ele, dentre essas definir quais delas são as críticas, normalmente são aquelas funcionalidades que não podem de maneira alguma apresentar problemas.
Por exemplo, um software de venda de mercadorias, foi identificado com o cliente que as funcionalidades de emissão de nota e cupom fiscal não podem apresentar problemas na sua execução, sendo esse um forte indicativo que teremos que planejar testes de regressão para estas rotinas críticas.

Testes redundantes
Nos casos de testes podemos ter planejados e escritos testes redundantes, que fazem a mesma execução no software e por isso não sendo possível revelar falhas diferentes quando executados. Percebendo a existência de teste redundantes não deveremos planeja-los para executar na etapa de testes de regressão, apenas devemos planejar os testes que possam revelar falhas diferentes quando executados.

Testes que falharam
Identificar as execuções de testes que em algum momento falharam, podemos ter essa situação nos testes das versões anteriores e também em chamados abertos pelos clientes relatando falhas, com essa base de testes e situações que apresentaram falhas, poderemos planeja-los para serem reexecutados na etapa de testes de regressão e assim evitar a sua recorrência.

Automatizar os testes de regressão
Com os testes planejados para executar na etapa de testes de regressão, por que executa-los manualmente? Sugiro que você e sua equipe automatize a execução destes testes, para ganhar agilidade e confiabilidade. Não irei entrar em detalhes do funcionamento da automação de teste, pois merece uma postagem apenas sobre esse assunto.

Concluindo então o meu primeiro post, espero que quando você e sua equipe forem planejar os testes de uma versão de software, não esqueçam de incluir a etapa de testes de regressão. E caso ela esteja presente em seu planejamento, siga as dicas apresentadas aqui no Nerds-On.

Muito Obrigado.

Referências

– ISTQB – Glossário padrão de termos utilizados em teste de software. Versão 2.2br (Janeiro 2012);
– Base de conhecimento em teste de software. RIOS, Emerson; CRISTALLI, Ricardo, MOREIRA, Trayahú; e BASTOS, Aderson. Editora Martins Fontes – 2007;
– Teste e análise de software – processos, princípios e técnicas. PEZZÈ, Mauro; YOUNG, Michal. Editora Bookman – 2008;
– Testes funcionais de software. MOLINARI, Leonardo. Editora Visual Books – 2008;