Quando falamos em testes de software, automação de testes é o termo do momento. Em um mundo onde a inovação é cobrada com frequência por parte dos clientes ao mesmo tempo em que a demanda pela qualidade dos produtos oferecidos cresce cada vez mais, é essencial assegurar-se que o que está sendo oferecido ao usuário está dentro dos padrões de conformidade esperados pelo mercado.
Neste cenário, trabalhar com automatização de testes pode ser interessante, muito por conta da promessa de ganhar tempo trazendo, em paralelo, resultados assertivos em termos de qualidade de software. Contudo, em muitos casos, ainda vejo que há certa dificuldade por parte das empresas em entender como aplicar tal estratégia da melhor maneira.
Seja pelo valor do investimento que essa iniciativa muitas vezes requer, tanto em dinheiro quanto em tempo, muitos gestores ainda parecem receosos frente a qual caminho tomar quando pensam em automatização de testes. É nesse cenário que muitos deles se deparam com ferramentas de captura e repetição (ou record and play).
Essas ferramentas, de início, prometem alguns benefícios, mas podem acabar se mostrando deficientes em atender as reais necessidades em termos de automatização de testes.
Nesse texto, explico mais sobre essas ferramentas e o porquê você deve ter cuidado ao optar por usá-las.
O que ferramentas de captura e repetição oferecem?
O que você acharia de poder configurar cenários de testes de seu site ou app apenas percorrendo os fluxos relevantes enquanto uma ferramenta memoriza o caminho e as ações tomadas, permitindo que, posteriormente, você consiga testar se o fluxo está funcionando como deveria?
Essas ferramentas ganham a atenção de profissionais de TI por conta de alguns fatores, principalmente a facilidade e a rapidez na gravação dos scripts: elas permite gravar um script de teste de maneira muito simplificada, inclusive inserindo validações customizadas em cada etapa. Em muitos casos, não é necessário nem conhecimentos em programação para realizar essas gravações.
Contudo, tal facilidade é limitada. Alguns fatores fazem com que essas ferramentas se tornem ineficientes em alguns cenários (como por exemplo, quando você precisa de uma massa de dados pré-cadastrada), podendo deixar a desejar em estratégias de automatização de testes.
Porque não usar ferramentas de record and play em automação de testes?
Dificuldade na manutenção dos testes e retrabalho
A situação mais indicada para fazer um uso real e proveitoso dessa ferramenta é quando se quer automatizar algo muito simples e que seja realmente estável – ou seja, que não passará por mudanças. Isso porque essas ferramentas, por darem acesso limitado ao código, acabam por não permitir alterações significativas nos caminhos testados.
Na prática, o que isso significa? Que, em muitos casos, caso a página que você quer testar passe por alguma modificação relevante, por menor que ela seja, você terá que regravar o teste desde o início.
Imagine só: você colocou tempo e esforço para gravar o teste para um dos caminhos mais críticos do seu aplicativo. Duas semanas depois a equipe de marketing solicita uma alteração na posição de um dos botões que leva à conversão. Após essa correção, o script de testes que você tinha basicamente foi inutilizado, pois a ferramenta de gravação não consegue identificar a mudança do elemento e você, por não ter acesso ilimitado ao código de testes, não indicar ao programa a nova posição do botão.
Isso impossibilita a manutenção dos scripts e gera retrabalho, uma vez que você não pode ficar sem a cobertura dos testes em seus principais fluxos e teria que regravar os cenários. Pois bem, agora pense: qual a recorrência em que você costuma a soltar atualizações dos seus produtos? No mercado, já existem empresas que liberam atualizações a cada minuto! Imagine ter que regravar os testes para cada uma dessas atualizações. Spoiler: posso te garantir que isso não será feito!
Quando falamos em testes automatizados utilizando ferramentas e frameworks robustos, com acesso total ao código, existe uma maior mobilidade nesses casos de mudança. Isso porque é possível alterar de maneira simples na própria linguagem de programação a ordem dos elementos a serem testados, não precisando descartar o teste a cada alteração.
Impossibilidade de se reaproveitar scripts
Outra dificuldade dos testes realizados com captura e repetição é o reaproveitamento.
Digamos, por exemplo, que você queira gravar cenários de testes para fluxos de compra em um aplicativo de delivery: um com cupom de desconto e outro sem cupom de desconto e, para cada um desses, cenários com pagamento em cartão de crédito, dinheiro e na hora da entrega, totalizando seis caminhos.
Para a gravação do primeiro cenário com ferramentas de record and play você levou cerca de 50 minutos, que é exatamente o mesmo tempo que você levará para automatizar cada uma dos outros 5 caminhos.
Em um contexto onde você codifica o teste, você pode até levar os mesmos 50 minutos para automatizar o primeiro cenário de testes, mas, pela semelhança entre os caminhos, seria necessário muito menos tempo para codificar as páginas restantes por já ter parte do fluxo codificado previamente. É possível aproveitar muito código para cenários semelhantes, poupando muito tempo na operação.
Testes presos aos profissionais que os realizam
Ferramentas de captura e repetição podem restringir muito a curva de conhecimento de seu time frente ao seu produto. Como?
Digamos que você tenha um profissional no seu time que cuide dos testes com essas ferramentas. Apesar de todas as dificuldades de manutenção no código, ele é alguém que entende do cenário dos testes gerados e, com o tempo, passa a ter certa agilidade para lidar com as ferramentas. Contudo, certo dia, tal profissional decide sair da empresa, levando consigo todo o conhecimento das ferramentas e do trabalho realizado.
A primeira vista isso pode não ser tão assustador, uma vez que você poderia substituir este colaborador por outro. Contudo, considere: se há acesso limitado ao código, como o novo profissional aprenderá sobre os cenários automatizados pelo colaborador anterior?
Entender os scripts gerados será bem mais demorado – e, enquanto o tempo de aprendizado está correndo, as mudanças no produto e a necessidade de manutenção dos scripts ainda existem!
E isso não é um cenário difícil de acontecer: conheço uma pessoa que me relatou que, em uma empresa na qual ela trabalhou, existiam mais de 200 casos de testes automatizados com ferramentas de captura e repetição. Um belo dia, a pessoa que dava manutenção nesses testes saiu da empresa e, quando este meu conhecido foi ajudar a dar continuidade ao trabalho, a falta de contexto sobre os testes realizados fez com que ele ficasse perdido e acabasse regravando diversos scripts.
Codificar esses testes, principalmente quando você utiliza técnicas de behavior driven development (BDD), oferece justamente o contexto que meu conhecido precisaria para se integrar na nova função e dar a continuidade mais assertiva à manutenção dos testes.
Inflexibilidade quanto à linguagem de programação
Um outro problema que essas ferramentas trazem é quanto à adaptabilidade: sua equipe de desenvolvimento (que é quem cuida dos insumos gerados pelos resultados dos testes automatizados) provavelmente está acostumada com uma linguagem de programação, que é usada diariamente. Acontece que, ao contratar uma dessas ferramentas, você geralmente não tem a liberdade de escolher em qual linguagem sairão os resultados do teste.
E agora? Se seu time programa em Ruby mas os testes saem em VBScript (O que é comum em ferramentas de Record and Play), qual é a solução? Eu adianto: você só estará agregando mais um problema na hora de dar manutenção aos testes.
Limitação em decidir o que e quando testar
Ferramentas de record and play seguem apenas fluxo e lógicas básicas de um produto. Ao utilizar tais ferramentas, há uma grande limitação em aprofundar a complexidade dos testes em determinados cenários.
Voltemos ao exemplo do app de delivery. Ao planejar os testes, você decide que precisa, por algum motivo, gravar um dos cenários sem inserir o endereço de entrega e que, ainda assim, o teste precisa dar certo. Ao codificar seu teste, esta necessidade pode ser facilmente implementada.
Já na captura e repetição, há uma limitação: para que o teste dê certo você necessariamente precisa percorrer exatamente todos os caminhos que o usuário percorreria. Neste caso, você não conseguiria fugir de colocar o endereço para que, no fim, a ferramenta considere que seu teste deu certo.
Agora, se você trabalha com metodologias ágeis, onde você busca integrar o QA ao longo do processo de desenvolvimento, te trago outro problema: você só conseguirá validar propriamente seus casos de teste quando o produto estiver definitivamente no ar, uma vez que a ferramenta precisa de acesso à aplicação para poder funcionar.
Em outras palavras, se você precisar criar o teste antes de ter o produto pronto, as ferramentas de captura e repetição não vão funcionar, travando seu processo ágil de desenvolvimento.
Um balanço final
Trouxe aqui alguns argumentos que elucidam porque você deve ter cuidado ao usar ferramentas de captura e repetição durante seu processo de quality assurance. Se, porém, eu pudesse ressaltar apenas um, seria a dificuldade na manutenção dos testes.
Certa vez ouvi a frase “your tests grows as your product grows”. Você realmente gostaria de limitar a evolução de seu produto pela dificuldade em dar manutenção em seus cenários de teste?
Afinal, até mesmo as pequenas mudanças em suas aplicação farão com que seus testes feitos com ferramentas de captura e repetição quebrem, te obrigando a gravá-los novamente, gerando perda de tempo e retrabalho.
