Automação de teste de software com QF-Test

Os tópicos abordados são:

• Escolha da ferramenta para automação de teste de software
• Planejamento da automação
• Priorização da automação
• Utilização de Procedures na automação
• Procedures Default QF-Test
• Utilização de variáveis na automação
• Aplicação dos recursos do QF-Test na automação
• Acompanhamento do andamento do projeto de automação

Este artigo será útil para quem pretende iniciar automação de testes de uma aplicação. Ele fornece uma base para que isso seja colocado em prática, para que analise todos os pontos necessários buscando informações para planejar e estruturar sua automação.

Sempre que pensamos em automação de testes de uma aplicação, o primeiro questionamento que surge é: qual a melhor ferramenta de automação a utilizar? Essa escolha deverá considerar os custos x benefícios que ela proporcionará para o produto. Existem diversas opções no mercado, open source e share, mas será que uma ferramenta free poderia atender todas minhas necessidades? É importante que se busque informações sobre elas, principalmente para identificar qual é a melhor opção que se adapta à plataforma do software que será automatizado.

A escolha da ferramenta seria o primeiro passo, no entanto, existem outras questões importantes que deverão ser avaliadas antes de colocarmos “a mão na massa”, ou seja, antes de começar de fato automatizar.

Algumas pessoas que não conhecem a fundo esse assunto podem ter a impressão que automação de teste de software se resume simplesmente em executar Record\Play. É preciso levar em consideração muitas questões relevantes para implantação da automação de um sistema, um item de muita relevância é a manutenibilidade, por exemplo. Quais padrões adotar para gravação dos testes de forma a facilitar compreensão do que o teste está fazendo quando for necessária alguma alteração devido à modificação de algum componente de uma tela, alteração de alguma funcionalidade ou até mesmo a quebra do teste quando executado devido à detecção de algum erro inserido no código?

Nesse artigo, essas questões serão comentadas sobre o que devemos avaliar antes de iniciar a automação dos testes de uma aplicação, nesse caso, utilizando a ferramenta QF-Test. Veremos a seguir alguns passos que podemos chamar de boas práticas a adotar-se em automação com QF-Test. Esta é uma ferramenta de automação de software para aplicações Java e web com uma interface gráfica (GUI).

Não entenda esses passos como necessariamente um script a ser seguido à risca. São diretrizes para ajudar no início de uma automação e quem sabe dar ideias para você que já utiliza repensar em algumas questões já implementadas. Ressalta-se que o conceito pode ser aplicado para outras ferramentas, porém é preciso salientar que é possível que nem todos os recursos que serão comentados existam nelas.

Escolha da ferramenta para automação de teste de software

Estudar, pesquisar e analisar informações sobre as ferramentas disponíveis no mercado é de extrema importância para tomada de decisão sobre qual ferramenta escolher para implantar a automação dos testes de sua aplicação. É interessante nessa etapa conversar com pessoas da área que já trabalham com automação, de preferência com as mesmas ferramentas que está pensando em adotar para coletar depoimentos práticos de pontos positivos e pontos negativos de sua utilização. Dessa forma, você poderá obter uma riqueza de informações com relação a cases vivenciadas por experiências com essas ferramentas, abstraindo essas práticas que não devem ser seguidas com a finalidade de não repetir possíveis erros já cometidos, muitas vezes que deixam “traumas” para esses profissionais que tiveram essas experiências.

Saiba mais: Testes de Software

É importante também considerar o custo, mas não somente o custo ligado diretamente a licença. Imagine que optando por uma open source, por exemplo, você pode não ter suporte às funcionalidades da ferramenta. O custo de uma escolha precipitada pode ser meses de trabalho perdidos em cima de um projeto que será abortado no meio.

Planejamento da automação

É de extrema importância que haja um planejamento da automação de teste, não somente com relação a metas estabelecidas e um cronograma a ser seguido, mas principalmente identificando melhores formas de gravar esses testes que podemos chamar de padronizações que serão adotadas.

Utilizando a integração contínua, qual ferramenta utilizar para essa finalidade é outra questão a ser avaliada. Encare a automação dos testes de sua aplicação como um projeto paralelo às atividades\testes manuais até que seja implantado e faça parte de seu processo.

Você pode estar se perguntando do que se trata integração contínua, como mostra um exemplo na Figura 1.

Integração contínua é uma prática de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.

Saiba mais: Curso de TESTE UNITÁRIO

O que geralmente acontece nestes casos é a aquisição de uma ferramenta que detecta os commits realizados para aplicação em outra ferramenta e, de acordo com a configuração, cria uma build com elas e executa os testes gravados com a finalidade de garantir que as últimas alterações não quebraram as funcionalidades já existentes.

A automação de testes é muito utilizada em testes de regressão. O ganho do tempo em executar um teste de regressão automatizado e manual não tem comparação, principalmente quando se fala em funcionalidades muito grandes e complexas. Um teste executado manualmente poderia durar dias. Podemos executar em horas através da automação. Isso não significa que teste automático exclui o teste manual, eles possuem abordagens diferentes, cada uma com sua importância.

Só para relembrar, quando falamos de testes de regressão estamos nos referindo a retestar funcionalidade já validada anteriormente a fim de garantir que ela continua funcionando quando alterações são realizadas em componentes pertencentes a essa funcionalidade.

Outra questão importante é sobre o ambiente de teste para automação: hardware que será utilizado, base de dados, configuração de servidores de aplicação e de banco de dados, rede, etc. Nessa etapa, também é recomendável que a troca de ideia com profissionais que já vivenciaram isso seja realizada como um guia para encontrar um rumo para seu novo projeto de automação que está em fase de desenvolvimento.

Priorização da automação

A priorização das funcionalidades que serão automatizadas também está relacionada um pouco com planejamento. Crie um backlog com todas as funcionalidades existentes em sua aplicação e defina qual o critério que será utilizado para ordenar sua lista.

Alguns exemplos de sugestões de priorização são:

• Por nível de complexidade da funcionalidade, da maior para menor ou vice-versa;
• Por funcionalidades mais utilizadas;
• Por funcionalidades mais críticas;
• Por funcionalidades definidas como mais importantes.

Enfim, analise de acordo com o negócio qual seria a melhor abordagem a adotar para as primeiras funcionalidades a serem automatizadas. Com essa definição, as ações a serem tomadas para que o objetivo seja alcançado torna-se mais fácil e provavelmente a melhor decisão para atender seu contexto atual será tomada.

Hipoteticamente, digamos que existam 50 funcionalidades, das quais todas são de conhecimento, e consenso que 15 delas são mais usadas. Dentre as 15, cinco são mais críticas, e das cinco críticas três são mais complexas. Ressaltando que complexidade e criticidade, apesar de parecerem sinônimos não possuem o mesmo significado. Uma funcionalidade crítica, ou seja, que não pode deixar de funcionar, não é necessariamente a mais complexa, ou seja, mais difícil, complicada de operar. Diante desse cenário, quais funcionalidades fariam mais sentido começar a automatizar? Começaria pelas mais complexas seguindo para mais críticas ou o contrário? Na sequência, contemplaria os testes automáticos para as mais utilizadas? São hipóteses, casos que deverão ser pensados e planejados de acordo com cada contexto. Lembre-se que é preciso ser flexível para repriorizar caso necessário após alguma mudança relevante.

Observe que ter listado todas as funcionalidades não é tudo. É recomendável que exista alguma documentação sobre o funcionamento dela. Diria que o mais adequado seria seguir casos de testes já escritos previamente para validá-las, até para garantir uma melhor cobertura dos testes que serão automatizados, prevendo vários cenários que podem existir. Além disso, assim como nos testes manuais, os casos de teste são guias dos passos que deverão ser executados para validarmos determinada funcionalidade, contendo a ação e qual o resultado esperado após executá-lo, conhecido também como roteiro de entradas\saídas.

Na criação do caso de teste poderão ser utilizados, como apoio, casos de uso ou até mesmo tabelas verdade, onde existem as variáveis envolvidas no processo e as possibilidades de casos que poderão ocorrer.

Utilização de Procedures na automação

A ferramenta QF-Test tem um recurso de criação de procedures. Através dele podemos criar packages para encapsular sequências de partes do teste que poderão ser reutilizados em mais de um teste, assim como mostra a Figura 2.

A utilização de procedures é muito importante principalmente para facilitar a manutenção do código gravado. Ao invés de chamar o mesmo componente em N lugares, ele estará centralizado somente em um lugar e poderá ser chamado sempre que necessário. Por esse motivo sua manutenção é bem mais simples. Por questões de organização do código, utilizar procedures também é uma boa prática.

Veja que as procedures ficam dentro de packages, então as procedures que se referem ao mesmo assunto podem ser reunidas na mesma package. No exemplo mostrado na Figura 3, foi criada uma package “checkers”. O componente check no QF-Test é utilizado para validar o valor de um campo, se ele está de acordo com valor default que foi atribuído para ele.

Para cada campo que foi criado um check, criamos uma procedure na package “checkers”. Dessa forma, sempre que for necessário validar esses campos, chamaremos a procedure referente a ele no teste.

Para reforçar ainda mais a ideia de reutilização de código, para os campos de valor podemos criar variáveis para que haja flexibilidade no valor utilizado. Falaremos mais sobre variáveis no próximo tópico.

No exemplo, onde foi criado o parâmetro “text”, poderia ser atribuída uma variável ao invés do valor 0. Sempre que realizar a chamada da procedure, é possível informar um valor diferente para esse parâmetro, mas é possível criar um valor default e só atribuir um novo valor quando houver necessidade de modificação.

Veja que existe um campo para comentário. Para facilitar futuramente quando precisar consultar esse teste para manutenção, recomenda-se que este campo sempre seja preenchido explicando o objetivo da procedure, informar quais são os parâmetros utilizados e como deverá ser feito seu preenchimento.

De modo geral, procedures podem ser criadas para login no sistema, cadastros\consultas que serão chamados mais de uma vez. Por exemplo, será criado o teste para validar o cadastro de cliente, no teste de CRUD. Poderão existir vários cenários para essa verificação e outros testes que tenham dependência com esse cadastro irão chamá-lo. Nesse caso, o indicado é que criemos procedure sempre que necessário fazer a chamada desse cadastro informando os campos de entrada da tela através de parâmetros.

Por questões de organização, você poderá criar um “qft” concentrando todas as procedures criadas. Não havíamos entrado em detalhes ainda, mas quando um teste é gravado no QF-Test, um arquivo com a extensão .qft é criado. Outro detalhe a se pensar é como será a melhor forma de organizar essa gravação nos qfts. Novamente frisando a questão de manutenção, um arquivo muito grande com todos os testes da aplicação gravados, somente em um qft, não seria recomendado. Uma dica é separar por menus, ou se forem muito grandes, por funcionalidades (criar um qft para cada funcionalidade que foi priorizada é uma possibilidade).

Por fim, depois de criada a package com suas procedures, elas serão chamadas nos testes. Veja um exemplo de como seria essa chamada na Figura 4.

Procedures Default QF-Test

Perceba que a chamada é feita sempre com o nome da package separado por “.” nome da procedure. Além de criar novas procedures, o QF-Test possui uma biblioteca com várias packages defaults que podem ser aplicadas para várias situações diferentes.

Na Figura 5 é apresentada uma listagem de todas as packages pré-existentes na ferramenta com um breve descritivo de sua aplicação.

Para cada package poderão existir N procedures. Entraremos em mais detalhes de algumas bem utilizadas, como:

• Menu: Essa package é utilizada para organizar a chamada de menu\sub-menus da aplicação, assim como mostra a Figura 6.

• Check: Dessa package temos duas procedures para ressaltar: compareTwoNumbers e compareTwoStringValues, ambas utilizadas para comparar dois valores identificando se é maior, maior igual, menor igual, de acordo com cada tipo de campo Number ou String. A única diferença para as duas procedures é o tipo do campo, o preenchimento será da mesma forma. Poderá ser utilizada, por exemplo, para confirmar se o valor de um campo que está sendo avaliado está retornado conforme o esperado. Nessa comparação podemos utilizar variáveis também.
• Database: Essa package possui duas importantes procedures: uma faz consultas no banco de dados (executeSelectStatement) e a outra faz chamada de procedures (executeStatement). Em ambos os casos, strings de conexões com o banco de dados serão passadas para que o comando do banco seja executado.

O resultado dessas chamadas poderá ser armazenado em variáveis e serão utilizados em campos de “Input” nos testes.

Utilização de variáveis na automação

A aplicação de variáveis em testes de automação permite maior flexibilidade na reutilização de componentes. Para utilizar uma variável, como em qualquer código, é necessário declará-la. Durante a execução dos testes, de acordo com o propósito da utilização, ela poderá receber outros valores.

A variável pode ser declarada através do componente Set Variable. Bons exemplos para campos tornarem-se variáveis seriam: valores, identificadores que não são gerados automaticamente, mensagens, nomes, etc. As sintaxes para declarar\atribuir valor a uma variável em QF-Test são:

• $(NomeVariável): No componente que irá fazer “Input” na tela ou checar esse valor em check text, por exemplo, ao invés de passar o conteúdo do campo será passado o nome da variável;
• ${ResultadoGrupo:NomeCampo}: Essa estrutura é utilizada para atribuir valor a uma variável depois de chamar um ExecuteSelectStatement. Nesse momento a variável será atribuída, será criado um nome para ela nessa construção;
• $[expression]: Atribuição de variável passando expressões numéricas.

É importante ressaltar que para facilitar a compreensão do código, os nomes criados para as variáveis deverão ser sugestivos. Em alguns casos, dependendo do grau de compreensão do código Java do testador, o mesmo padrão utilizado na codificação para nomes de packages, procedures, variáveis poderão ser utilizados para os testes também. Um ponto de atenção é evitar utilizar nomes duplicados para não haver problemas de atribuição de valores.

Todas as variáveis que receberam valores durante a execução do QF-Test podem ser visualizadas no menu: Edit \ Options \ Variables, assim como mostra a Figura 7.

Na Figura 8 é possível ver um exemplo de como uma variável pode ser chamada em um componente. Para uma Sequence Login, ao invés de deixar fixo o nome de usuário e senha, foram criadas variáveis para que esses valores sejam dinâmicos cada vez que forem chamados.

Outra forma de atribuir valor a uma variável é através do “Fetch Text”. Esse componente do QF-Test permite que o conteúdo de algum campo da tela seja armazenado nele em forma de variável para ser utilizado adiante na gravação do teste, geralmente, na consulta, para garantir que o novo cadastro salvo, após a consulta, possua valor do campo X com mesmo conteúdo.

Aplicação dos recursos do QF-Test na automação

O QF-Test possui vários recursos que podem ser utilizados para deixar os testes automáticos mais inteligentes como, por exemplo, controle de estruturas com os comandos condicionais: Loop, While, Break, If, Try. Esses comandos podem ser utilizados para inserir repetições da chamada de um mesmo teste N vezes ou incluir condições para executar cada teste.

O loop, por exemplo, pode ser configurado para uma sequence (componente que organiza a sequência dos testes no QF-Test) a ser executada a quantidade de iterações definidas na gravação do teste.

No exemplo representado na Figura 9 foi criado um loop para abrir e fechar uma dialog executando o que estiver dentro do loop. A quantidade de vezes é definida na variável $(count) e o contador inicial do loop é definido pelo campo “Iteration counter”.

Outro recurso que pode ser explorado é a criação de códigos Java no teste quando existe conhecimento do mesmo. É possível escrever linhas de código usando as variáveis que foram criadas chamando através do componente alguma formatação ou validação mais específica via codificação, conforme mostrado na Figura 10.

Acompanhamento do andamento do projeto de automação

Com planejamento definido, é hora de colocar a mão na massa! Começaremos a gravar os testes automáticos e executá-los.

O QF-Test possui alguns relatórios que podem ser gerados em XML ou HTML mostrando o resultado da execução dos testes, quantidade total de testes existentes no qft, duração, quantidade de testes que falharam, passaram, não foram executados, entre outros, conforme pode observar na Figura 11.

Ainda comentando sobre as falhas, é possível ver o screenshot do momento do erro, e um log com todas as informações dos componentes que foram percorridos e valores carregados, facilitando a triagem da identificação da origem do erro.

É importante ressaltar que ao longo do projeto é necessário fazer um acompanhamento para identificar se o andamento de cada etapa está dentro do planejado, se existe necessidade de mudanças para atingir o objetivo almejado. Essas são questões que devemos ficar atentos para termos flexibilidade de mudanças, para tomar ações e fazer com que nosso projeto de automação realmente seja efetivo.

Automatização de teste não se trata simplesmente de record\play, existem vários fatores envolvidos que precisam ser estruturados, relacionados a arquitetura dos testes, para que ao longo do tempo o retorno da automação dos testes seja percebido, principalmente nos testes de regressão.

É preciso ter o cuidado ao elaborar testes automáticos padronizados, bem estruturados de forma que facilite a manutenção. Além disso, é preciso estruturar os testes pensando no tempo de execução total também. O intuito de sua aplicação é melhorar os processos ajudando a garantir a qualidade das aplicações.

Não se desespere caso no início, o que aparentemente se trata de um teste simples de tela, exija algum tempo maior envolvendo aprendizado e familiarização com a ferramenta. Pense nos ganhos a longo prazo que testes automatizados podem trazer. Com o tempo você ganhará agilidade tanto para gravação, quanto para manutenção e compreensão da origem dos erros de execução.

É importante ressaltar também que os testes automáticos de maneira alguma excluem ou isentam a execução dos testes manuais, principalmente com relação aos testes exploratórios. Devemos vê-los como complementares. Termos uma funcionalidade automatizada é muito importante, mas é preciso entender que manter uma suíte de testes automáticos rodando exigirá intervenções manuais, seja para construção, manutenção, identificação e/ou report dos defeitos.

Caso já possua parte de sua aplicação automatizada, pense a respeito dos tópicos abordados, análise o que poderia absorver para trazer para seu projeto de automação de forma a aprimorá-lo. Para quem ainda não começou, analise, estude os pontos, busque informações, planeje, estruture sua automação de forma que ela traga os resultados esperados e aprimore seus testes.