Testes de Regressão: Manuais ou Automáticos?

A questão que surge em cada fase do desenvolvimento é que os testes de regressão após cada iteração levam muito tempo, e muitas vezes a funcionalidade que está a ser validada não sofreu alterações. Consequentemente, a possibilidade de existirem defeitos é muito baixa. Como resultado natural, chegamos a uma ideia de automatizar todos os cenários de regressão e em detrimento dos testes manuais de regressão. As vantagens são evidentes:

• os testes automatizados são mais rápidos do que os manuais ;
• os testes automatizados podem ser realizados em qualquer momento;
• os testes automatizados são muito precisos;
• a automatização pode ser utilizada em quase todos os processos de teste;
• pode-se criar relatórios com base nos resultados da automatização.

Mas, infelizmente, a automatização dos testes de regressão tem muitas armadilhas que raramente são discutidas.

Antes de começar a automatizar testes de regressão é necessário resolver algumas questões: 

• Que funcionalidade deve ser coberta pelos testes;
• Definir a arquitectura dos testes automáticos;
• Escolher uma ferramenta para automatizar de testes de regressão.

Vamos ver situações reais na prática. Na fase de mudança de testes manuais para testes automatizados, tive um projecto onde eu tinha que testar o registo de dois tipos de contas para um site em 43 domínios, consoante país. Era um autêntico inferno. O cliente não se preocupava com a qualidade da informação apresentada. Os requisitos eram os seguintes:

• as contas são criadas sem erros fatais ;
• os dados introduzidos coincidem com os valores que são exibidos nas configurações após a criação.

Depois de duas execuções percebi que era demais. Na altura, só conseguia ver que o número de campos de registo é diferente em alguns países e também tinha alguma experiência em programação em C#. Havia a possibilidade de automatizar os testes regressão e não hesitei. Pedi a um amigo familiarizado com automatização para descrever e mostrar como se escrevem testes. Depois de muitas perguntas, tentativas e erros, nasceu um teste simples de navegação. Descobri locators e web drivers Selenium - e eis que, todos os domínios utilizavam os mesmos locators. Pouco mais tinha para fazer: executar última regressão manual da minha vida em todos os domínios e preencher a tabela com os correspondentes campos e domínios. Outra sessão de regressão manual - um longo processo para fechar o círculo - e tudo parecia terminado.

Gozei cada uma das regressões seguintes. Pude assistir a algumas séries de TV enquanto executava a regressão. E, por sinal, cada uma demorava apenas o tempo de um episódio. Enquanto eu costumava gastar cerca de 4 a 5 horas em testes de registos nos 43 domínios, os testes de regressão automatizados demoravam 40 a 45 minutos.

Considerando isto, podemos chegar à conclusão nº1: para ver as vantagens da automatização de testes, devemos começar com os testes mais frequentes, que geralmente são positivos, e que devem ser executados após cada release.

Isso continuou durante várias releases até que a empresa decidiu oficialmente automatizar a maioria das funcionalidades. E como o cliente não era muito conhecedor em testes de automatização decidimos automatizar toda e qualquer coisa que caísse no âmbito do meu conhecimento de automatização de testes.

Como resultado, cobrimos quase todo o sistema com testes automáticos. Tudo estaria bem, mas depois de qualquer correcção alguns testes começavam a falhar. Na maioria dos casos, isso acontecia porque tínhamos grandes scripts que tinham muitos passos:

·         Num primeiro passo do teste o sistema era colocado num determinado estado; quando o erro surgia no segundo passo, já não tinha sentido executar os restantes passos;

·         Cenários longos contêm muito código e acções como estas; como resultado, repetir os primeiros passos podia fazer com que muitos testes falhassem.

·         Devido à repetição do código, os testes automáticos validam o mesmo ponto muitas vezes, o que provoca um aumento desnecessário da duração dos testes.

Com base nisso, podemos chegar à conclusão nº 2: cenários demasiado longos devem ser executados manualmente, pois consome-se muito tempo a escrevê-los e estes podem falhar devido a pequenos bugs ou erros de menor importância.

Vamos considerar uma outra situação muito interessante. O cliente pediu testes automáticos, como é habitual, e solicitou que apresentássemos alguns exemplos. Ele aprovou a ideia, e alguns dias depois adicionamos automatização de testes ao planeamento. Mas os nossos programadores atrasaram-se e, os testers tiveram que escrever testes automáticos com base numa versão provisória. Dois dias depois os programadores concluíram o trabalho, mas mais da metade dos testes automáticos falhou.

Conclusão nº 3: nunca começar a escrever testes automatizados, sem que exista uma versão estável.

Há pouco tempo atrás, tivemos uma situação engraçada. Tínhamos recebido um pedido de testes automáticos a um site e tudo tinha de ser feito rapidamente. Tudo correu melhor do que nunca. Algumas semanas depois, o cliente enviou uma carta reclamando que os testes não funcionaram. Percebemos que ele tinha iniciado um redesenho do site e todos os testes tinham falhado. Isto ensinou-me a fazer testes estáveis.

Portanto, a conclusão n º 4 é: quando for possível, usar os locators de modo que os elementos possam ser encontrados após pequenas mudanças.

Assim, as vantagens de testes manuais vêem-se claramente: não dependem de nada e podem ser feitos em qualquer momento. Prescindir dos testes manuais não vai trazer nada de bom. Testes manuais e automáticos estão inter-relacionados e complementam-se; cada um tem vantagens e desvantagens. Antes de pensar em automatizar cenários de regressão devemos avaliar o tempo a escrever os dois tipos de testes e o apoio destes. E lembre-se que os especialistas em testes manuais geralmente ganham menos do que aqueles que têm competências em automatização de testes.

Como sempre, é tudo uma questão de dinheiro. Se a automatização de cenários de teste de regressão economiza dinheiro sem perder a qualidade do produto, então pode-se alargar o leque de cenários automatizados, elevando a qualidade do produto e reduzindo custos. O ponto de equilíbrio é uma decisão de cada um de nós e depende da experiência e das preferências pessoais.

--------------------------------

Traduzido e adaptado de: Regression Testing: Manual Or Automated? (With Examples)