As armadilhas da automatização de testes

Automação, às Fatias

Não se pode negar que a automatização de testes revolucionou os testes de software. E mesmo a tempo! No mundo atual de serviços ultradistribuídos, contentorizados e continuamente atualizados, realizar testes de software significativos seria impossível sem ela.  

Temos a sorte de dispor de tantas ferramentas de testes automatizados sofisticadas. E, permitam-me acrescentar, de engenheiros de QA bem treinados para as utilizarem em benefício de todos no processo de desenvolvimento.

No entanto, por alguma razão, é da natureza da nossa indústria reduzir habitualmente avanços tão significativos em termos de capacidade a modas passageiras, e essas modas a saladas de palavras sem significado e slogans que são repetidos roboticamente por gestores de topo, comentadores e consultores que apenas querem uma desculpa para deixar de pensar no problema. Ou para ganhar dinheiro rapidamente.  

É isso que está a acontecer com os avanços na automatização de testes, que foram rapidamente incorporados na narrativa redutora de que «só precisamos de automatizar todos os nossos testes! Já! E todos os nossos problemas de testes ficarão resolvidos!»

Não só esta é uma péssima ideia, mesmo que fosse proposta por pessoas que estão a tentar levar o problema a sério e não apenas a evitá-lo. É também perniciosa, porque é uma narrativa que, ao eliminar a oportunidade de pensar profundamente sobre como integrar a automatização nos esforços de testes, garante o seu fracasso.  O que é injusto para todas as pessoas (incluindo os clientes) que dependem do seu sucesso.

Neste aspeto, a automatização de testes está simplesmente a herdar um caso particular da abordagem geral à SQA por parte daqueles que não a compreendem, nem querem compreendê-la. É tratada como um produto a granel, e não como uma especialização complexa. É por isso que as pessoas de QA continuam a ouvir da gestão de topo: «só precisamos de mais QA!», como se existisse algures uma charcutaria de software onde se pudesse encomendar QA ao quilo, cortado em fatias finas.

É por isso que o mantra atual é «só precisamos de mais automatização!», sem qualquer reflexão sobre o que isso significaria realmente no contexto dos esforços de desenvolvimento do seu software. Como tal, este discurso alimenta as disfunções da sua organização. Não as resolve.  

Tentar resistir diretamente a estas tendências passageiras é como tentar impedir o nascer do sol. Ou, neste caso, o pôr do sol. A melhor forma de resistência é simplesmente acenar e sorrir aos vice-presidentes e consultores, regressar aos seus cubículos e descobrir a forma correta de fazer automatização, apresentando depois essas ideias como produtos brilhantes da imaginação dos seus gestores. Mas provavelmente já aprendeu essa lição com outros assuntos.

Então, façamos isso. Eis a minha lista das armadilhas da implementação da automatização de testes e das formas de as mitigar, para que a automatização possa cumprir a sua considerável promessa nos seus próprios esforços de testes.

Âmbito da Automatização

A pergunta mais importante a responder no início é em que áreas os testes automatizados oferecem o melhor retorno no âmbito dos seus esforços de testes. Dedicar algum tempo a fazê-lo irá poupar-lhe muitas, muitas dores de cabeça mais tarde.

Responder a esta pergunta resume-se a saber que parte dos seus testes precisa de ser automatizada e quanta deve continuar a ser manual. Isto poderá ser surpreendente para aqueles que são incessantemente bombardeados pelo evangelho de «automatizar todos os testes!». Mas não dê atenção a esse disparate; essas pessoas não fazem ideia do que estão a dizer.

Automatizar todos os seus testes — partindo do princípio de que isso é sequer possível — seria uma péssima decisão, que só poderia conduzir ao desastre nos seus esforços de testes.  

Há coisas extraordinárias que a automatização consegue fazer e que os testes manuais não conseguem, ou pelo menos não conseguem fazer com a mesma rapidez e repetição. Mas o inverso também é verdade. Há coisas que apenas os testes manuais conseguem fazer bem e que a automatização não consegue. Quais são essas coisas em cada caso?

Onde os testes manuais se destacam relativamente aos testes automatizados é simplesmente no fator humano. O benefício de ter uma pessoa real a realizar pacientemente testes exploratórios aprofundados não pode ser reproduzido pela automatização. E não estou a falar apenas da descoberta de erros.  

Qualquer pessoa pode encontrar erros. Os clientes fazem-no gratuitamente a toda a hora. O valor acrescentado por um profissional de QA é ter uma noção intuitiva de como quebrar uma parte de software, especialmente no sentido de determinar como o software pode ser utilizado pelos clientes de formas para as quais nunca foi concebido e que, ainda assim — frequentemente com resultados catastróficos —, são possíveis. 

Outra vantagem dos testes manuais é que, depois de encontrar um erro, um testador manual pode imediatamente determinar o seu âmbito e gravidade. Isto é, restringir os contextos de teste (sistemas operativos, fluxos de trabalho, interações e dependências entre serviços) em que o erro se manifesta especificamente e aqueles em que não se manifesta. 

Os scripts de testes automatizados não conseguem fazer isto bem e, do ponto de vista de um engenheiro de software, esta é precisamente a informação crucial de que precisam para diagnosticar e corrigir qualquer erro. Um relatório de erros que se limite a afirmar «fiz isto e aconteceu esta coisa má» é inútil para eles.

Na verdade, os testes manuais são muito mais eficientes em termos de tempo para fornecer esta informação e, por serem inerentemente interativos e decorrerem em tempo real com a equipa de engenharia, proporcionam um feedback e uma análise da causa-raiz muito mais ricos em informação.  

Sim, Virgínia, os testes manuais nem sempre são a forma menos eficiente e mais demorada de encontrar, diagnosticar e corrigir erros, e de validar (ou não) as respetivas correções. 

Onde a automação tem uma vantagem óbvia, contudo, é nos testes contínuos do tempo de atividade e da estabilidade — particularmente no caso de sistemas distribuídos. Isto é algo muito mais central atualmente, tendo em conta o nosso contexto de desenvolvimento atual de integração e implementação contínuas em ambientes distribuídos, em tempo real.

A automação também é mais eficiente naquilo a que se pode chamar “testes em massa”, em que se tem uma enorme matriz de milhares de condições do sistema e respetivas variáveis a abranger, para verificar se alguma delas está completamente avariada ou fará o sistema falhar.

A regra geral que deve utilizar para orientar as suas decisões sobre onde dar prioridade aos testes manuais ou automatizados é a seguinte: 

Os testes manuais são geralmente preferidos para os testes iniciais de novas funcionalidades e capacidades. Os testes automatizados são claramente os melhores para a regressão geral contínua e para os testes de carga e desempenho.

Ao longo do ciclo de vida de um produto ou serviço, os testes da mesma capacidade devem evoluir de manuais para automatizados. É um contínuo do ciclo de vida da capacidade. Não é uma muralha chinesa, que nunca deve ser transposta, sem que nenhum dos lados precise de estar ciente do que acontece no outro. A suposição predefinida deve ser a de que aquilo que é testado manualmente hoje deve transitar para testes automatizados ao longo do tempo.

Qualificações de um Engenheiro de Automação

É talvez inevitável que, ao contratar engenheiros de testes automatizados, as principais qualificações procuradas sejam os níveis de proficiência dos candidatos (a) nas ferramentas de automação que deverão utilizar e (b) nas linguagens de criação de scripts de testes utilizadas por essas ferramentas.  

Mas, se estas forem as únicas qualificações em que se está a concentrar, está a cometer um grande erro. São qualificações necessárias, mas estão longe de ser suficientes para a função de engenheiro de automação.

Porquê? Pela simples razão de que saber utilizar uma ferramenta de automação e criar scripts na respetiva linguagem de criação de scripts não lhe diz absolutamente nada sobre a compreensão que essa pessoa tem da própria garantia da qualidade.

Infelizmente, quase nunca encontro engenheiros de automação que tenham esta formação ou experiência. São contratados simplesmente porque são especialistas na criação de scripts, não porque tenham competências para conceber um teste eficaz e de diagnóstico.

Estas qualificações são, na realidade, mais importantes do que a experiência com as ferramentas e linguagens de automação que irão utilizar. Podem aprender facilmente estas últimas, se necessário. Mas é preciso muito tempo e esforço para ensinar alguém a conceber testes e a interpretar os seus resultados.  

Na verdade, seria melhor pegar num analista experiente que já tenha e dar-lhe formação nas ferramentas de automação necessárias. Afinal, estas competências de automação são agora uma mercadoria. A intuição e a perspicácia de um profissional de testes experiente não são.

Automatizar a ignorância apenas lhe dá ignorância mais rapidamente e de forma mais repetível, prejudicando a eficiência que procurava obter com os testes automatizados. 

Normas de Conceção da Automação

É óbvio que, se está a iniciar um esforço de automação de testes em grande escala, terá primeiro de definir normas gerais às quais toda a automação deve obedecer para ser aceite para utilização nos testes. No entanto, tal como acontece com muitas coisas óbvias, parece haver menos bom senso do que seria de esperar.

Eis o que essas normas devem abranger.

Inteligibilidade

Um dos mistérios frustrantes do desenvolvimento de software é o seu caráter artesanal. Infelizmente, não é de todo raro um engenheiro de software dizer-lhe que não consegue corrigir um erro porque não foi ele que escreveu o código onde este aparece. É como se o código escrito por outro engenheiro estivesse numa língua estrangeira que não compreende.

Infelizmente, isto também é igualmente comum na engenharia de automação de testes. Não lhe consigo dizer quantas vezes um engenheiro de QA me disse que não sabe como atualizar uma parte da automação de testes para uma grande atualização do produto porque não foi ele que a escreveu e, por isso, não a compreende nem consegue compreendê-la. Ah, e o engenheiro que a escreveu deixou a empresa há dois meses.

Isto é ainda menos aceitável no caso dos scripts de testes automatizados do que no caso de código de software novo que implementa lógica de conceção, e não apenas faz com que determinados passos ocorram. No entanto, é surpreendentemente comum.

O que isto significa é que, antes de contratar uma dúzia de engenheiros de QA e os pôr alegremente a produzir centenas de scripts de testes automatizados, deve certificar-se primeiro de que definiu e deu formação sobre normas gerais de inteligibilidade.  

Deve ser um requisito que todos os scripts de testes sejam mutuamente inteligíveis para qualquer um dos seus engenheiros de QA, para que não acabe por ficar dependente de um único recurso, muitas vezes transitório, para a sua manutenção.  

Defina e imponha um processo de revisão/aceitação de todos os candidatos a scripts automatizados face a estas normas antes de poderem ser implementados nos testes. 

Manutenibilidade

A manutenibilidade está estreitamente relacionada com o problema da inteligibilidade; no entanto, as duas são lógica e operacionalmente separadas. Um script de testes pode ser facilmente compreendido por engenheiros de testes que não o escreveram e, ainda assim, estar estruturado de tal forma que seja uma verdadeira aberração atualizar ou modificar.

Eis um exemplo da vida real. 

Numa das empresas onde trabalhei, estávamos a preparar o esforço de testes para uma atualização de nível intermédio do seu produto principal. Estava previsto um ciclo de lançamento de quatro semanas, o que, neste caso, era bastante razoável.

Enquanto planeava o esforço de testes necessário, percebi que também teríamos de atualizar o principal script automatizado de testes de regressão. Quando perguntei ao engenheiro de QA responsável quanto tempo demoraria essa atualização, respondeu-me “oito semanas”. O dobro do tempo de todo o lançamento! Mesmo tendo em conta o pecado de engenharia de inflacionar estimativas, isto era extremo.  

Pedi a alguns outros engenheiros de testes que analisassem o script e a estimativa. Todos concordaram que o script tinha sido escrito de uma forma tão desajeitada e ineficiente que seriam necessárias muitas semanas de reescrita meticulosa de todo o script para o atualizar para o lançamento seguinte, apesar de as atualizações em si não constituírem reescritas fundamentais do produto.

Aquela situação era um exemplo clássico de um pecado da engenharia de software teleportado para a engenharia de testes. Está na altura de acabar com esta loucura.

O meu conselho aqui é idêntico ao que dou acima sobre a questão da inteligibilidade. Não permitam, em circunstância alguma, que os vossos engenheiros de QA se escondam nas suas cavernas de engenharia de testes e apareçam uma ou duas semanas mais tarde com algo que possa funcionar como teste, mas que seja um pesadelo de sofrimento sem sentido para atualizar atempadamente.

Estabeleçam normas para a possibilidade de atualização atempada e criem um processo de revisão e aceitação para garantir que isso acontece. Isto pode ser facilmente integrado nos mesmos esforços para garantir a inteligibilidade, pelo que tudo pode fazer parte do mesmo processo de revisão.

Os vossos engenheiros de QA não são pintores renascentistas; não lhes estão a pedir para repintar a Capela Sistina. Isto não deveria demorar uma vida inteira.

Funções nos testes e automatização de testes

Um dos padrões de ineficiência que impede a integração fluida e produtiva da automatização no esforço de testes como um todo é a suposição errada de que cada passo do processo de testes automatizados tem de ocorrer dentro do próprio grupo de automatização.

Este é outro erro. Embora, neste caso, não seja inteiramente óbvio.

É provável que os engenheiros de automatização sejam os recursos mais bem pagos da vossa equipa, pelo que o tempo deles é precioso. Além disso, o volume de scripts de testes que essa equipa terá de criar e atualizar continuamente só vai aumentar com o tempo, enquanto o vosso conjunto de engenheiros de testes não conseguirá crescer quase suficientemente depressa para acompanhar esse ritmo. Nem mesmo se trabalharem para a Google.

Faz sentido do ponto de vista operacional, portanto, introduzir alguma divisão do trabalho entre a equipa de automatização e o resto da equipa. Mais especificamente, a divisão entre os recursos que criam e mantêm scripts e ferramentas automatizados e aqueles que executam efetivamente os testes automatizados.

É evidente que as primeiras responsabilidades só podem ser desempenhadas pela própria equipa de automatização.  Afinal, foi para isso que foram contratados. No entanto, o mesmo não é verdade relativamente às últimas.  

Não há razão para que os analistas não possam também executar testes automatizados por conta própria e interpretar os respetivos resultados.  

Muito poucas pessoas pensam nestes termos, mas esta divisão do trabalho faz todo o sentido. Por um lado, liberta uma quantidade significativa de tempo, permitindo que os engenheiros de automatização se concentrem na criação de novas automatizações.

Por outro lado, reforçará o requisito de inteligibilidade definido acima. Se a automatização for central no vosso esforço de testes, então é igualmente essencial que todos os elementos da vossa equipa de testes, sejam ou não engenheiros de automatização, consigam compreender e utilizar os vossos testes automatizados. Até mesmo os testadores manuais.

Um sistema deste tipo, baseado na definição de funções, aumentará significativamente a flexibilidade de recursos de toda a vossa equipa de QA e, consequentemente, criará também eficiências de tempo e de planeamento que, de outro modo, não existiriam. 

Considerações finais

Desenvolver uma capacidade robusta de testes automatizados, conforme definido acima, é simplesmente uma necessidade nos dias de hoje. Não é possível falar de QA profissional e eficaz sem ela.  

No entanto, muitas aventuras promissoras começam com entusiasmo e alegria, apenas para acabarem derrotadas no final da jornada. Vejo isto acontecer no QA relativamente à automatização de testes em muitas, muitas situações.

O problema é que é relativamente fácil mergulhar nos testes automatizados. São dispendiosos, mas é fácil, pelo menos, fingir que se está a fazer um esforço. Contudo, os testes automatizados também podem ser um precipício do qual se corre, como o Wile E. Coyote nos desenhos animados do Papa-Léguas, correndo inadvertidamente para fora dele e caindo no momento em que se olha para baixo.

É necessário compreender desde o início que a automatização de testes tem um ciclo de vida. Cada script de testes tem um ciclo de vida de meses, quando não de anos.

Não se trata apenas de escrever um conjunto de scripts de testes automatizados que satisfaçam todas as necessidades do produto tal como este se encontra atualmente no seu desenvolvimento. Trata-se de saber como poderão evoluir de forma contínua todas essas automatizações à medida que o produto evolui ao longo do seu próprio ciclo de vida.

Se ignorar os problemas relacionados com o âmbito da automação, as qualificações dos engenheiros de QA, a inteligibilidade, a manutenibilidade e a definição de funções, descobrirá que, com o tempo, todo esse esforço de automação se tornou um elefante branco e um poço sem fundo, impossível de compreender ou manter.

E todo o dinheiro que gastou com isso terá sido desperdiçado. Algo que os chefes dos seus chefes não deixarão de notar.

Por outro lado, se seguir os conselhos que apresento acima, adaptados, naturalmente, às particularidades dos seus próprios desafios e da sua situação, evitará em grande medida esta crise de obsolescência e desfrutará dos frutos de uma automação de testes produtiva durante muitos anos.

Como sempre, boa sorte.

Leituras relacionadas:

• 10 MELHORES FERRAMENTAS DE MONITORIZAÇÃO DE SERVIDORES WEB
• MELHORES PRÁTICAS DE AUTOMAÇÃO NA TRANSFORMAÇÃO DIGITAL

Vale a pena ver: O QUE É O MABL? VISÃO GERAL E VISITA GUIADA ÀS FUNCIONALIDADES