Skip to main content
Crowdtesting

Dicas para uma boa automação de testes

Por: Stenio Viveiros, MSc, CSQA, CTAL (Full)

É comum ver em diferentes projetos de automação de testes, alguns problemas nos scripts que causam atrasos, insatisfação ou mesmo desistência da automação no projeto. Por isso, neste artigo será discutido um pouco sobre esses problemas e como não cometê-los mais. Em resumo, os principais problemas encontrados nos scripts de testes são:

  • Demora excessiva para a execução;
  • Diversas “quebras” no momento das execuções;
  • Alta manutenção durante o projeto.

Dicas para uma boa automação de testes

Primeiramente, só podemos considerar que uma automatização de testes funcional está bem construída se os scripts já estiverem executando, por exemplo, de 4 semanas a 4 meses.

Não se pode avaliar um script de testes somente por uma única execução, pois têm questões de performance do aplicativo sendo testadas, a massa de testes que varia, novas versões do aplicativo testado, dentre outros.

Considerando os pontos acima, a seguir será discutido cada um dos problemas de uma má automação de testes.

Demora Excessiva para a Execução

Suítes de teste de longa duração podem sugar a confiança de seu projeto. Testes funcionais na interface do usuário serão sempre muito mais lentos do que outros tipos de testes, não se pode ter um ambiente de automação produtivo e de confiança caso os testes sejam executados uma vez por mês ao longo de um fim de semana.

Você precisa de um tempo de execução moderadamente curto, assim você pode ter seus testes executando várias vezes ao dia.

Tenha em mente a escala de tempo neste contexto: 800 testes (tendo 30 segundos por teste), levarão cerca de sete horas para serem executados. Pequenas mudanças podem lhe render ganhos enormes quando a quantidade de testes é grande.

Causas da demora para execução dos testes:

  • Infraestrutura deficiente: 

Você não deve executar os testes em série. Dimensione de alguma forma uma grade e paralelize sua execução. Obtenha hardware razoável para hospedar seu aplicativo e os agentes de execução de testes. Obtenha tudo isso conforme planejado no início de seu projeto para que você não tenha que suar quando estiver pressionado.

  • Utilização do browser para a configuração de ambiente: 

Ações no browser são muito lentas, além de serem frágeis. Nunca use o navegador para a criação de dados, pré-requisito ou configuração.

Sempre busque uma API de apoio para lidar com esse tipo de coisa. Você pode economizar uma enorme quantidade de tempo de seus testes de configuração, empurrando para fora do navegador para uma API.

  • Teste excessivo: 

Só porque você pode automatizar alguma coisa não significa que você deva. Concentre-se em testes de alto valor em torno de suas necessidades de negócio mais críticas ou nas áreas de maior risco. Considere a combinação de teste manual e teste exploratório manual.

  • Navegação onde não há a necessidade: 

A navegação é cara. Sempre que possível, pule login, navegação e outras etapas desnecessárias. Você até pode tentar modificar o sistema para ser capaz de ignorar estas ações. Você pode testar esses passos em outros lugares, é claro, mas não todas as vezes!

Diversas “quebras” no momento das execuções

Testes “quebram” por razões estranhas. Testes quebradiços funcionam em ambientes dos automatizadores, eles falham quando executado em sua suíte, mas passam quando executado individualmente.

Causas da ocorrência de testes quebradiços:

  • Efeitos colaterais:

Cada teste deve ser autossuficiente e granular. Pré-requisitos de testes precisam ser configurados e sempre que possível, serem limpos. (Rollback do banco de dados de transações!).

Testes não podem sempre confiar no estado definido por outros testes, isso não significa que você não possa usar um conjunto de dados de base para configurar amplos conjuntos de pré-requisitos, mas você deve certificar-se de limpar após a execução.

  • Ambientes ruins:

Dicas para uma boa automação de testes

Você não pode esperar ambientes ruins ficarem estáveis. Por exemplo, imagine um projeto onde espera-se que os testes funcionais rodem no servidor de integração contínua, porém, esse servidor é constantemente alterado por versões de 20 desenvolvedores simultaneamente.

imagem

Esse servidor possui um banco de dados na mesma máquina usado por outros servidores e além disso, esse servidor é uma máquina virtual em um hardware ruim. Obtenha ambientes de testes realistas.

  • Testes complexos ou mal projetados:

Estes se encaixam nos efeitos secundários mencionados acima. Também estão relacionados com mantenabilidade dos scripts, conforme descrito a seguir.

Classes com preocupações mistas, muitas responsabilidades, alto acoplamento com a interface do usuário ou com outros componentes. Esses fatores soam apenas como problemas que vemos na construção de sistemas. Eles também impactam os scripts de testes. Preste atenção na forma como você está construindo seus testes!

Alta manutenção durante o projeto

Alta manutenção durante o projeto de automação de testes

Se não tiver cuidado, você pode facilmente gastar mais tempo mantendo os seus testes automatizados atualizados do que você gastaria na criação de novos ou mesmo fazendo teste exploratório.

Roy Osherove, em seu livro “The Art of Unit Testing” fala sobre um projeto que falhou porque sua equipe passou muito tempo fazendo manutenção dos testes. Note que eles não abandonaram seus testes e todo o projeto falhou!

De acordo com minha experiência, em testes funcionais e de interface, a causa número um da alta manutenção é a pobre gestão dos localizadores de elementos, efeitos colaterais e projeto de testes pobres contribuem, mas falha na gestão de localizadores é a causa principal.

Eles (localizadores) são também a forma do seu framework de testes/ferramenta encontrar elementos na página ou no aplicativo.

Caso você não seja cuidadoso, vai acabar gastando um tempo enorme arrumando localizadores dos seus testes a cada vez que a interface do usuário mudar, mesmo que sejam mudanças pequenas e/ou localizadas. Imaginem que mude a tela de login. Possivelmente todos seus scripts serão afetados.

Dois fatores ajudam a reduzir a dificuldade na gestão de localizadores:

  • Centralize a definição do localizador:

Este é um lugar para aprender, viver e amar o princípio do reuso. Ter localizadores definidos em mais de um lugar em seu código-fonte é uma receita para a tragédia.

Se você estiver escrevendo testes puramente baseados em código, então procure por algo como o Padrão Objeto de Página, um dicionário simples ou até mesmo um conjunto de campos de somente leitura.

Ferramentas como o HP Quick Test Professional são úteis através da criação de um banco ou repositório de elementos que centralizam o armazenamento e manutenção de localizadores. Tendo um armazenamento centralizado de localizadores, basta somente ir em um lugar para atualizá-los. Todos os testes remetem a esse repositório para ler a definição do localizador.

Assim a manutenção dos seus scripts será muito mais fácil.

  • Prefira bons tipos de localizadores sempre que possível: 

Localizadores são geralmente baseados em atributos HTML (ou na sua estrutura- DOM) ou CSS. Nem todas as ferramentas ou bibliotecas apoiam os vários tipos de localização.

 Seguem informações sobre alguns dos tipos mais comuns de localizadores:

  1. Os valores de “HTML ID”são o número um, a melhor maneira de especificar os seus localizadores. IDs são únicos na página, assim você nunca está ambíguo. IDs não mudam com base em sua posição na página, então caso um campo seja transferido para outro lugar na página, seus testes devem funcionar bem. IDs são resolvidos mais rapidamente.
  2. O texto ou link.Algumas bibliotecas vão deixar você localizar um elemento pelo seu link de texto ou pelo texto no campo. Isso é útil, no entanto, pode não ser único na página ou pode mudar mais facilmente.
  3. Seletores CSSsão coisas como nomes de classes CSS. Estes são bastante rápidos para resolver, mas não é garantida a exclusividade na página, então eles podem não funcionar.
  4. O XPath.XPath trabalha com a estrutura DOM com base em caminhos e funções. Nosso lado “Nerd” que adora expressões regulares também adora XPath.

É possível resolver alguns problemas muito complicados com XPath. No entanto, XPath é difícil de compreender, e é extremamente frágil. Caso algo se ​​mova um pouco no DOM da página, o seu XPath pode ser totalmente desconfigurado.

Além disso ele é extremamente lento no Internet Explorer. Finalmente, o XPath na plataforma .NET não está totalmente implementado, da mesma forma que pode ter um bom funcionamento em ferramentas como o XPather no Firefox pode não funcionar em ferramentas de teste construídas em .NET.

Desde o início de um projeto de automação de testes é importante considerar todos os aspectos acima e também seguir as boas práticas de desenvolvimento de software. O código dos scripts de testes deve ser considerado como código-fonte de produção e assim receberam as mesmas preocupações.

Sete Pecados da Automação de teste

Sete Pecados da Automação de Testes

A alta gerência normalmente vê a automação de testes como a solução para reduzir esforço e custo de testes no aumento das entregas do software. Enquanto é verdade que os testes automatizados podem prover um rápido retorno sobre a qualidade do sistema, o trabalho para construir os testes automatizados não é. Há alguns problemas conhecidos que precisam ser evitados, além dos citados acima.

  1. Gula

Ceder muito às ferramentas de testes proprietárias.

Muitas ferramentas de testes comerciais fornecem recursos simples para automatizar a captura e reprodução de casos de teste manuais.

Embora essa abordagem pareça boa, ela incentiva teste através da interface de usuário e resulta na fragilidade e dificuldade de manter os testes. O custo e as restrições que as ferramentas comerciais colocam para quem pode acessar os casos de teste é uma sobrecarga que tende a impedir o trabalho de colaboração e de equipe.

Além disso, o armazenamento de casos de teste fora do sistema de controle de versão cria uma complexidade desnecessária.

Como alternativa, as ferramentas de teste open-source geralmente podem resolver problemas de testes mais automatizados e os casos de testes podem ser facilmente incluídos no sistema de controle de versão.

É preciso haver um equilíbrio e uma correta avaliação para cada projeto quando utilizar ferramentas comerciais ou ferramentas open-source.

  1. Preguiça

Preguiça de configurar um servidor de Integração Contínua para a execução de testes.

Os custos e rápido retorno dos testes automatizados são melhores percebidos quando os testes são regularmente executados. Se os testes automatizados são iniciados manualmente e não através do sistema de integração contínua, há um risco significativo de que eles não são executados regularmente e, sendo assim, podem na verdade estar falhando.

Faça um esforço para garantir que os testes automatizados sejam executados através do sistema de integração contínua.

  1. Luxúria

Adorar a interface do usuário de forma que todos os testes sejam executados através dela.

Apesar dos testes automatizados de interface do usuário fornecer um alto nível de confiança, eles são caros de construir, lentos e difíceis para manter.

Testar no nível mais baixo possível do código é uma prática que incentiva a colaboração entre desenvolvedores e testadores, aumenta a velocidade de execução de testes e reduz os custos de automatização dos testes.

Testes de unidade automatizados devem constituir o maior esforço de teste seguido de testes de integração, sistema, funcionais e de aceitação. Testes de interface do usuário somente devem ser usados quando o foco dos testes são as telas dos usuários ou não há alternativa prática.

  1. Inveja

Criar testes de forma ciumenta e não colaborar.

TDD (Test Driven Development) é uma abordagem ao desenvolvimento que é tanto uma atividade de modelagem quanto uma prática de teste.

O processo de definição de casos de teste (ou especificações executáveis) é uma maneira excelente de assegurar que haja um entendimento comum entre todos os envolvidos quanto à exigência real quanto ao que está sendo desenvolvido e testado.

A prática é muitas vezes associada aos testes de unidade, mas pode ser igualmente aplicada a outros tipos de teste, incluindo testes de aceitação.

  1. Raiva

Frustração com testes frágeis que se quebram de forma intermitente.

Testes não confiáveis ​​é uma das principais causas das equipes ignorarem ou perderem a confiança em testes automatizados.

Uma vez que a confiança é perdida, o valor inicialmente investido em testes automatizados é drasticamente reduzido. Corrigir testes que falham e resolver problemas associados com testes quebradiços devem ser prioridades para eliminar falsos positivos.

  1. Orgulho

Pensar que testes automatizados substituirão todos os testes manuais.

Testes automatizados não são um substituto para o teste exploratório manual. Uma mistura de tipos e níveis de testes é necessária para alcançar a qualidade desejada e mitigar o risco associado com defeitos.

O teste do triângulo automatizado originalmente descrito por Mike Cohn explica o perfil de investimento em testes e deve concentrar-se no nível de unidade e depois reduzir-se nos próximos níveis.

  1. Avareza (Ganância)

Muitos testes automatizados que não mapeiam a qualidade do sistema.

O esforço de teste precisa corresponder ao nível de qualidade desejado do sistema. Caso contrário há o risco de pouca ou nenhuma funcionalidade correta ser testada. É importante definir a qualidade exigida e depois combinar o esforço de teste para se adequarem.

Esta abordagem pode ser feita em colaboração com os envolvidos nos projetos para garantir que há um entendimento comum dos riscos e potenciais implicações.

Referências:

  • http://frazzleddad.blogspot.com/2011/12/31-days-of-testingday-11-maintainable.html
  • http://www.agileengineeringdesign.com/2012/01/7-deadly-sins-of-automated-software-testing
  • Practical Web Test Automation, Zhimin Zhan
  • Lessons Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord

Compartilhar Com
Conteúdos que você pode se interessar

Um comentário em “Dicas para uma boa automação de testes

  1. Bem legal essa análise sobre atividades relacionadas à Teste de Software. Atuo na área à quase 4 anos e reconheço que a falta de um “padrão” no desenvolvimento de software implica (e muito) na manutenção dos testes automatizados (como mencionou o autor).

    É claro que se o profissional tiver um vasta experiência, ele vai conseguir contornar esse problema através de PageObjects ou contando com auxílio de variáveis para identificar os elementos de forma dinâmica.

    Porém, é bem mais viável alinhar juntamente com a equipe sobre a importância atribuir identificação única aos elementos da página (como ID e Name). Fiz isso no meu antigo trabalho e a equipe correspondeu bem.

Deixe uma resposta para Hugo Peres Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *