Liderança em Testes: Ferramentas de Execução de Testes

Automatização de testes (execução)

O tema da automatização de testes (normalmente através de uma interface gráfica do utilizador) está no topo da agenda da maioria dos testadores e gestores de testes. À primeira vista, estas ferramentas parecem oferecer grandes possibilidades, mas muitas organizações que pretendem automatizar parte ou a totalidade dos seus testes funcionais deparam-se com problemas.

Não iremos entrar em demasiados detalhes técnicos neste artigo, mas abordaremos alguns dos problemas relevantes para os gestores de testes e de projetos que precisam de criar um caso de negócio para a automatização. Iremos analisar:

• O que obtém e não obtém com as ferramentas de execução de testes
• Automatização de testes através de uma interface gráfica do utilizador (GUI)
• Automatização de testes de API e de serviços
• Testes de regressão
• Estruturas de automatização de testes

É importante definir expectativas realistas sobre aquilo que a automatização pode e não pode fazer, pelo que as próximas secções poderão parecer algo pessimistas.

O que obtém e não obtém com as ferramentas de execução de testes

Quer esteja a testar aplicações de ambiente de trabalho Windows, websites ou dispositivos móveis, os princípios da automatização de testes, bem como as suas vantagens e desvantagens, são semelhantes. O que obtém com as ferramentas é:

• Um robô incansável e supostamente isento de erros, que executará quaisquer testes programados que pretenda, a pedido e com a frequência que desejar.
• Uma comparação precisa entre a saída e/ou o resultado dos testes e os resultados esperados preparados, com o nível de granularidade que estiver disposto a programar na ferramenta.

O que não obtém é:

• Flexibilidade e respostas fluidas a anomalias, falhas ou comportamentos questionáveis.
• Os olhos e o raciocínio de um testador humano, capaz de tomar decisões para explorar, questionar, experimentar e desafiar o comportamento do sistema em teste.
• Testes gratuitos. Continua a ter de conceber testes, preparar dados de teste e resultados esperados, por exemplo.
• Embora as ferramentas de execução de testes ofereçam várias funcionalidades, muitas vezes carecem de capacidades avançadas de armazenamento de dados. Para uma solução mais abrangente, poderá explorar o melhor software de gestão de bases de dados disponível.

Vamos explorar a importância destas vantagens e problemas.

Se for um programador razoavelmente competente, é simples implementar como procedimentos automatizados, na linguagem de criação de scripts da sua ferramenta, testes procedimentais executados por seres humanos, para que a ferramenta os execute com precisão.

Desde que o ambiente e os dados utilizados pela sua aplicação de teste sejam consistentes, pode esperar que os seus testes sejam executados de forma fiável, repetidamente. Esta é a promessa óbvia da execução automatizada de testes.

Contudo, os testes automatizados não simulam com precisão aquilo que os bons testadores fazem durante os testes.

Um teste executado por uma ferramenta NÃO é equivalente ao mesmo teste executado por um ser humano.

Um teste, se tiver um script, poderá indicar ao testador o que fazer. Contudo, os testadores conseguem olhar para além da simples comparação entre um resultado esperado e o resultado apresentado no ecrã.

Os testadores têm de navegar até à localização do teste e estar atentos a comportamentos anómalos — a resposta aos comandos; a velocidade da resposta; o aspeto do ecrã; o comportamento dos objetos afetados pela alteração do estado da aplicação.

Ao observar uma anomalia, o testador humano poderá fazer uma pausa, refazer os passos ou analisar mais profundamente a aplicação ou os dados antes de concluir se a aplicação funciona corretamente (ou não) e se deve continuar o teste programado, ajustar os dados e o script do teste ou prosseguir conforme previsto.

Os seres humanos são flexíveis, ao passo que as ferramentas só fazem exatamente aquilo para que são programadas. Numa transação baseada no ecrã, a ferramenta introduz dados, clica num botão e verifica a existência de uma mensagem ou de um resultado apresentado – e é tudo. Com testadores humanos, obtém-se muito mais do que aquilo que tomamos como garantido. 

Em princípio, é possível programar uma ferramenta para realizar todas as verificações que um ser humano faz instintivamente – mas terá de escrever muito código e passar tempo a depurar os seus testes. Mesmo assim, não obterá a capacidade humana de decidir o que fazer a seguir – fazer uma pausa, continuar, alterar o teste a meio ou explorar uma anomalia mais aprofundadamente.

Em nenhum outro caso é tão evidente a inflexibilidade das ferramentas como quando reagem à perda de sincronização do script com o sistema em teste. Talvez um resultado esperado não corresponda, o sistema bloqueie ou o comportamento da interface do utilizador (uma ordem alterada dos campos ou um novo campo, por exemplo) seja diferente daquilo que o script espera. O que faz a ferramenta? Tenta continuar e segue-se uma torrente de falhas ou bloqueios do script. 

Sim, pode e deve ter no seu script gestores de eventos não planeados para detetar falhas de teste. A perda de sincronização, as incompatibilidades entre o estado do sistema e os dados de teste, as alterações na ordem dos campos, os novos campos ou os campos removidos são situações que o testador consegue reconhecer e tratar sem que os testes tenham de parar. As ferramentas não conseguem fazer isto sem um grande esforço de programação da sua parte.

Também existem desvantagens em utilizar seres humanos para seguir testes baseados em scripts. Os testadores podem ficar obcecados em obedecer ao script e esquecer-se de utilizar as suas capacidades de observação. Podem não detetar anomalias evidentes porque se concentram em seguir o script. Esta abordagem menos do que ideal é exatamente aquilo que obtemos com a automatização da execução de testes.

A adesão cega aos scripts de teste é uma má ideia para os testadores humanos, mas é o melhor que conseguimos fazer com a automatização de testes.

Nesta comparação entre testadores que seguem scripts e ferramentas que executam testes, não considerámos o que fazem os testadores exploratórios. A abordagem exploratória dá aos testadores a liberdade de investigar e testar onde e como quiserem. 

É evidente que as ferramentas não conseguem simular esta atividade. Mais importante ainda, as ferramentas não conseguem definir o âmbito, estabelecer prioridades e modelar a funcionalidade e os riscos de um sistema, nem conceber testes em conformidade.

As atividades de análise e conceção de testes são necessárias independentemente de um teste ser executado por uma pessoa ou por uma ferramenta.

Existem outras restrições relativamente ao que as ferramentas de execução de testes podem fazer:

• As ferramentas de execução de testes fazem exatamente aquilo para que são programadas – nem mais, nem menos
• Normalmente, as ferramentas não executam a criação e configuração dos ambientes e das aplicações, nem o carregamento dos dados de teste
• As ferramentas não concebem casos de teste ou scripts, nem preparam dados de teste e resultados esperados
• As ferramentas não conseguem tomar decisões ponderadas quando ocorrem eventos inesperados.

Para otimizar os seus processos de execução de testes, integrá-los com um software robusto de gestão de testes pode proporcionar fluxos de trabalho simplificados e relatórios melhorados.

Automatização de testes da interface gráfica do utilizador (GUI)

Passaram cerca de vinte e cinco anos desde que as ferramentas de automatização de testes de GUI entraram no mercado, mas o número de implementações falhadas de ferramentas de testes de GUI continua a ser elevado. Isto deve-se sobretudo ao facto de as expectativas relativamente à automatização serem demasiado elevadas – e as ferramentas utilizadas sem disciplina nunca as conseguirão cumprir.

As ferramentas de automatização de testes de GUI têm reputação de serem fáceis de utilizar enquanto produtos, mas difíceis de gerir quando as aplicações em teste (e, consequentemente, os scripts de teste) precisam de ser alteradas. Estas ferramentas são muito sensíveis a alterações na interface do utilizador. Alterações na localização, na ordem e no tamanho, bem como a adição ou remoção de objetos do ecrã, podem afetar os scripts. Alterações mais técnicas, como a mudança do nome dos objetos do ecrã ou a alteração de bibliotecas GUI incorporadas “invisíveis”, também causam problemas.

A automatização de testes de GUI funciona melhor quando existe disciplina relativamente a:

• O processo de desenvolvimento e as alterações e versões são geridos cuidadosamente. Por exemplo, é analisado o impacto das alterações e os testadores são notificados. 
• A abordagem ao desenvolvimento de scripts de teste. Os engenheiros experientes de automatização de testes adotam convenções sistemáticas de nomenclatura, estruturas de diretórios, componentes modulares e reutilizáveis, técnicas de programação defensiva, entre outras.

A criação de scripts para a automatização de testes é uma tarefa que exige mais do que conhecimentos básicos de programação e, acima de tudo, experiência em automatização e na ferramenta utilizada. Quando os testes são automatizados em grande escala, são também necessárias competências de conceção. 

Independentemente da forma como as ferramentas são descritas pelos fornecedores – “sem scripts”, “utilizável por não programadores” ou “os utilizadores também podem automatizar” –, continua a ser necessária uma mentalidade de programador, competências de conceção e uma abordagem sistemática.

Automatização de testes de API e de serviços

Quando existem componentes ou funcionalidades implementados como serviços, chamados por clientes leves ou móveis, os testes serão realizados utilizando uma API ou através de chamadas de serviço. Este modo de teste é realizado utilizando código personalizado escrito por programadores ou ferramentas específicas de teste de API ou de serviços. Em qualquer caso, a abordagem habitual consiste em automatizar os testes de uma forma ou de outra.

Como a API está «mais próxima» do código a testar, os testes podem ser muito mais direcionados para a funcionalidade a testar. Certamente, podem ser ultrapassadas as complexidades da navegação através da IU e dos próprios testes através da IU. Por este motivo, a regra geral é:

Se a funcionalidade em teste (ao nível do código ou do componente) puder ser testada através de uma chamada de função, de uma API ou de um serviço, a automatização será mais fácil — e é recomendada.

Os testes através da API têm vantagens evidentes.

• Embora tenha de utilizar ou escrever código, os próprios testes serão muito mais fáceis de aplicar (não há uma IU com que se preocupar).
• Depois de uma chamada à API ser transformada num script, basta tabular o conjunto de casos de teste que pretende aplicar. Não há limite para o número de testes que pode aplicar.
• Os testes baseados em API são normalmente executados muito mais rapidamente, tornando este estilo de testes adequado a abordagens de entrega contínua, nas quais o pipeline de implementação é altamente automatizado e precisa de responder rapidamente.

O «modelo de pirâmide da automatização de testes» (uma pesquisa no Google apresentará centenas de exemplos do gráfico) foi adotado quase universalmente para apresentar a recomendação de que os esforços de automatização de testes se devem centrar mais nos testes do programador ou da API do que nos testes através da interface gráfica do utilizador.

• Utilize testes da IU quando for necessário executar o fluxo de trabalho do utilizador, mas em baixo volume, porque os testes são dispendiosos e podem ser lentos a executar.
• Utilize chamadas à API ou a serviços quando a funcionalidade em teste puder ser isolada e quando a velocidade e a facilidade de automatização forem essenciais.

Testes de regressão

A utilização clássica de ferramentas automatizadas consiste na execução de testes de regressão. Estes testes são executados uma vez e considerados representações precisas do comportamento esperado. Quando o código da aplicação em teste, as bibliotecas reutilizáveis associadas ou o ambiente de teste sofrem alterações, estes testes fornecem alguma confiança de que a funcionalidade necessária não foi afetada negativamente pela alteração.

Pode imaginar os testes automatizados como um molde no qual o sistema em teste encaixa. Naturalmente, os testes devem «passar» todas as verificações que foram executadas anteriormente. Ao voltar a executá-los, está a tentar demonstrar a equivalência funcional da nova versão do software em comparação com a anterior. Existem alguns princípios simples que deverá seguir:

• Em primeiro lugar, os testes e as verificações realizados devem ser selecionados de modo a dar-lhe confiança de que não estão presentes alterações indesejadas no comportamento. Estes testes funcionam como um «fio de alarme» para detetar diferenças no comportamento.
• Quando são corrigidos erros ou realizadas outras alterações de software, pode haver casos de comportamentos que são alterados (corretamente), mas que, quando encontrados pelos seus testes, fazem com que uma verificação falhe. Terá de alterar os seus testes antecipadamente ou deixá-los falhar e corrigi-los posteriormente. Por vezes, é mais rápido eliminar completamente os testes que falham e criar novos testes de raiz para os substituir. Em qualquer caso, estes testes alterados devem então ser executados até ao fim e passar.
• Se o sistema em teste não for estável, tiver muitos erros ou estiver a sofrer alterações extensas entre versões, poderá não ser viável manter economicamente um conjunto de testes automatizados. Embora a funcionalidade do sistema não sofra alterações, é possível que a interface do utilizador continue a evoluir — uma IU instável também torna a manutenção da automatização mais difícil. O custo da investigação das falhas dos testes e da manutenção dos testes pode superar a sua utilidade. Poderá ser sensato testar manualmente as partes menos estáveis do sistema até estas estabilizarem.

Testar através da interface do utilizador pode ser, por vezes, trabalhoso, dispendioso e lento. Antes de iniciar a automatização de testes da interface gráfica, ou mesmo de automatizar um único script, é prudente considerar se testar a funcionalidade principal seria mais fácil, rápido e económico através de uma API.

A utilização clássica de ferramentas automatizadas consiste na execução de testes de regressão. Para garantir que está a utilizar as ferramentas mais eficazes para este fim, consulte a nossa lista das principais ferramentas de teste de software

Estruturas de automatização de testes

As estruturas de testes são uma parte essencial de qualquer processo de testes automatizados bem-sucedido. Pense nelas como um conjunto de orientações a utilizar na criação e conceção de casos de teste. A sua utilização pode aumentar a velocidade e a eficiência da sua equipa de testes, melhorar a precisão dos testes, reduzir os riscos e diminuir os custos de manutenção dos testes. Vamos agora analisar duas destas estruturas.

Ao discutir estruturas de automatização de testes, é essencial considerar o papel das ferramentas de automatização de QA na definição de uma estratégia de testes eficaz.

Estruturas de testes unitários

As estruturas de testes unitários existem há alguns anos e são amplamente utilizadas pelos programadores para testar o seu código. Os testes dos programadores tendem a ser bastante localizados — afinal, normalmente testam um único componente, com as interfaces para outros componentes ou bases de dados simuladas ou substituídas por implementações fictícias. Assim, embora os testes unitários necessitem de etapas de configuração e desmontagem antes e depois da execução dos testes, estas tarefas tendem a limitar-se à execução de testes de um único componente. Existiriam conjuntos de testes separados para cada componente.

Os testes unitários criados pelos programadores são normalmente controlados por versões e geridos em paralelo com o código dos componentes. Normalmente, as funcionalidades de Integração Contínua (CI) obtêm o código-fonte e todos os testes unitários e executam-nos após cada confirmação de novo código e/ou testes. Todos os programadores veem o resultado destes testes, pelo que uma falha num teste de CI se torna muito visível. A correção de testes e código com falhas é uma prioridade elevada nas equipas que utilizam CI desta forma, para que a versão mais recente do sistema passe sempre todos os testes de CI.

Estruturas de automatização de testes de integração e de sistema

Nos últimos anos, as ferramentas de teste de GUI foram integradas com ferramentas de CI através de dispositivos de teste virtualizados, ambientes virtualizados e execução através de interfaces de linha de comandos. Muitas organizações conseguiram integrar completamente a execução de testes unitários, ao nível da API e de GUI através de serviços de CI.

No entanto, muitas equipas de testes continuam a operar os seus próprios ambientes de teste, separados do desenvolvimento ou dos serviços de CI. Estas equipas tendem a criar as suas próprias estruturas de automatização de testes, porque as ferramentas de CI são demasiado orientadas para programadores ou porque as ferramentas proprietárias são inadequadas.

Os testes de GUI tendem a implementar testes de ponta a ponta ou percursos de utilizador utilizando diferentes aplicações, dispositivos de hardware e ambientes. Estes testes precisam de configurar de forma integrada ambientes de teste e dados de teste preparados em diferentes plataformas, o que exige procedimentos privilegiados e complexos, bem como ambientes técnicos diversificados para a sua operação. A grande maioria das equipas que utiliza a automatização de testes de GUI cria as suas próprias estruturas de automatização, únicas mas eficazes.

As estruturas de automatização de GUI variam em sofisticação, desde ferramentas semelhantes às de testes unitários até funcionalidades complexas e abrangentes, necessárias para gerir ambientes, compilações de aplicações, grandes volumes de dados de teste, mensagens e sincronização entre plataformas e ambientes, bem como mensagens e notificações para os membros da equipa.

Algumas ferramentas proprietárias incluem utilitários ou estruturas de suporte para gerir, executar e gerar relatórios a partir de conjuntos de testes automatizados. Estas funcionalidades têm um valor variável, pelo que muitas organizações criam as suas próprias estruturas de automatização de testes para as ampliar. Nos últimos anos, o âmbito das estruturas de automatização cresceu e já não existe uma definição única ou simples. Por isso, vejamos agora o que as estruturas de automatização de testes podem fazer pelas equipas de software.

Uma estrutura de automatização de testes amplia a funcionalidade dos motores de execução de testes.

Configuração de conjuntos de testes

A estrutura integra testes automatizados em coleções ou agrupamentos significativos de testes. Estas coleções são configuráveis, permitindo executar os testes numa hierarquia de sequências, grupos ou seleções arbitrárias. Estas ferramentas podem incluir funcionalidades para conduzir os testes por dados, utilizando tabelas de dados de teste preparados. Este é o tipo mais simples de estrutura — as ferramentas populares costumam disponibilizar alguma forma de configuração de conjuntos de testes.

Configuração e limpeza

A estrutura trata de todas as atividades de configuração e limpeza de um único teste, de uma coleção ou de todo um conjunto. A configuração pode envolver a criação de ambientes de teste a partir do zero, configurações completas e o pré-carregamento de bases de dados de teste e de outras fontes de dados a partir do zero. A limpeza pode envolver a remoção de dados de teste ou a reposição ou eliminação de ambientes parciais ou completos. A estrutura pode integrar-se com ferramentas de orquestração de pipelines e estar sob o seu controlo.

Gestão de exceções

Uma falha em qualquer teste — quer ocorra no sistema sob teste, quer resulte de uma perda de sincronização — pode ser tratada de forma consistente através do registo do evento e, normalmente, permitindo que os restantes testes dessa coleção continuem a ser executados. A estrutura pode ser programada para tratar falhas nas verificações de testes, perdas de sincronização, tempos limite de execução e outros resultados de teste selecionados — cada um com procedimentos personalizados.

Registo e mensagens

A estrutura regista de forma consistente a execução dos testes e o estado da execução em todas as coleções de testes. A estrutura aciona relatórios a partir das ferramentas que executam os testes ou fornece um registo consistente de todas as atividades de configuração, execução e limpeza dos testes. A estrutura pode interagir com robôs ChatOps para informar a equipa sobre exceções e permitir que os membros da equipa coloquem em pausa, parem, repitam ou reiniciem conjuntos de testes.

Abstração de testes com linguagem específica do domínio

Surgiram no mercado dois tipos distintos de estruturas que abstraem o código de execução de testes para modelos ou para texto legível por humanos ou não técnico:

• As estruturas orientadas por palavras-chave permitem definir testes utilizando palavras-chave. As chamadas às funcionalidades do motor de execução são implementadas como comandos semelhantes ao inglês, com marcadores de posição para parâmetros ou dados. Os módulos reutilizáveis definidos pelo utilizador podem ser definidos e chamados utilizando comandos em texto simples da mesma forma. Existem estruturas para todos os tipos de interfaces, incluindo GUI, serviços, API, interpretadores de linha de comandos, entre outras. Os scripts podem testar funcionalidades em diferentes plataformas de sistemas operativos e dispositivos.
• As estruturas de Desenvolvimento Orientado ao Comportamento (BDD) permitem registar histórias e cenários (exemplos) que descrevem o comportamento das funcionalidades utilizando uma linguagem específica do domínio (DSL). A linguagem mais popular é a chamada Gherkin, que utiliza a estrutura linguística “dado … quando … então …” para registar exemplos. Dado/quando/então representam efetivamente as pré-condições, os passos e as pós-condições dos casos de teste. As ferramentas de BDD convertem o texto dado/quando/então em «chamadas de passos» numa linguagem de programação. O programador (ou testador) tem de implementar os «dispositivos de teste» ou o código que efetua chamadas a um motor de execução de testes. Desta forma, a linguagem de um requisito (a história) pode ser ligada diretamente ao código de execução textual.

Estruturas baseadas em modelos

Neste caso, as ferramentas permitem criar um modelo do sistema em teste. Este modelo pode ser derivado automaticamente de uma página Web, na qual a ferramenta analisa o HTML, deteta formulários e campos e cria um modelo a partir do qual os percursos através dos formulários podem ser gerados automaticamente ou selecionados pelo testador. Também é possível criar manualmente mapas de objetos para aplicações móveis ou outros dispositivos inteligentes. Utilizando os percursos através do mapa de objetos, são efetuadas chamadas às funcionalidades do motor de execução de testes de forma semelhante às ferramentas BDD e orientadas por palavras-chave. Em princípio, é possível criar testes graficamente sem escrever código. As ferramentas deste segmento são relativamente recentes e estão a melhorar rapidamente. É de esperar que a sua utilização se acelere no futuro.

Subscreva o boletim informativo da The QA Lead para receber uma notificação quando forem publicados novos artigos da série. Estes artigos são excertos do curso Liderança em Testes de Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter $60 de desconto no preço total do curso!

Leitura relacionada: 10 MELHORES FERRAMENTAS DE MONITORIZAÇÃO DE SERVIDORES WEB