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)
