7 Pecados Capitais da Automação de Testes

O artigo retrata práticas em comum nos projetos de automação de testes, independente da tecnologia. Originalmente dedicado para profissionais menos experientes, mas quem sabe pode refletir a sua realidade.

Em primeiro lugar

Antes de falarmos sobre os 7 pecados, tenho duas perguntas a fazer.

• Você sabe o que significa Pecados Capitais?
• Quais são os estes?

O que são Pecados Capitais?

Estava o tempo todo na nossa cara rs

Epístolas de Paulo definem os Pecados Capitais como, “vícios de conduta”.

Enfim

Apresento a vocês os 7 Pecados Capitais da Automação de Testes:

1. A Avareza dos Dados Hardcode
2. A Gula do Record and Play
3. A Luxúria de Não usar Design Patterns
4. A Soberba de Não efetuar asserções corretas
5. A Inveja de Identificar elementos por Full Xpath
6. A Preguiça de Não indentar o código
7. A Ira de Não documentar as Dependências

A Avareza dos Dados Hardcode

Não acumule dados HardCode.

Quando deixamos os dados fixos dentro da nossa estrutura de automação perdemos algumas características importantes, por exemplo:

Confidencialidade

• Informações sigilosas, como dados bancários, telefone e endereço.

Segurança

• Podemos expor dados de acesso a aplicação;

Reutilização

• Ao manter os dados hardcoded não conseguimos utilizar essa massa em outro momento, podendo causar duplicidade de código.

# Sugestão 💡

• Armazenar os dados em um arquivo de apoio(data-driven)
• Definir esses dados como Argumentos na sua especificação do cenário.

A Gula do Record and Play

Para que tanto script?

Existem tecnologias de Record and Play para automação de testes como o SeleniumIDE, esta ferramenta não é recomendada para grandes projetos pelos seguintes motivos:

Reutilização de código

• Se você já usou uma ferramenta de Record and Play sabe que é gerado um script a cada gravação com configurações inicias, por exemplo, definição de navegador, URL base, timeout etc. Com isso, dentro de uma bateria de testes, essas configurações irão se repetir várias vezes. Além de trazer todos elementos pelo qual a gravação interage, impede um padrão de projeto e gera mais código do que de fato é necessário.

Consistência

• Esse script de automação que foi gerado não é doutrinado para usar boas práticas(brincadeiras a parte), portanto essa automação pode estar fragilizada, pois não foram mapeados elementos adequados e implementadas validações assertivas.

Escalabilidade

• Pelos motivos já mencionados acima, seria muito difícil de manter um projeto de grande escala, organizado, performático, atualizado e assertivo.

# Quando usar Record & Play? 💡

• Eu recomendaria utilizar essas tecnologia apenas para uma Demo, onde você que não domina o assunto precisa disso a curto prazo ou apenas para um entendimento inicial.

A Luxúria de não usar Design Patterns

O desejo incessante pelo GoHorse

Siglas como GoF e MVC já estão na ponta da língua dos desenvolvedores e o mesmo deve ser feito com os Engenheiros de Qualidade. Já ouviram falar de Page Objects ou Singleton? Veja o que você perde sem eles.

Organização

• Ao estabelecer um padrão de projeto você tem uma arquitetura bem definida, permitindo uma organização do seu projeto em larga escala. Outro benefício é poder organizar elementos e métodos dentro de um objeto e até modularizar o seu projeto, isso ajuda no crescimento da sua produtividade, tendo em vista que isso pode ser instanciado e acessado a qualquer momento.

Manutenção

• Dado que seu projeto esteja organizado, quando for necessário uma manutenção(principalmente em automação WEB/MOBILE) você terá maior facilidade nessa tarefa, levando em conta que você já sabe onde é necessário introduzir essa correção e que será feita em apenas um lugar.

# Qual Design Pattern adotar? 💡

• Essa resposta vai depender da necessidade e tecnologias utilizadas no seu projeto de automação, sugiro procurar profissionais mais experientes da sua empresa ou da comunidade QA e analisar o bônus e ônus de cada um.

A Soberba de não efetuar asserções corretas

Acredite em mim

Existem situações em que ao concluir uma etapa dentro de um cenário de teste automatizado(por exemplo, login ou cadastro) profissionais acreditam ser o suficiente para a conclusão do teste. As vezes isso é feito de forma inconsciente, pois o objetivo do cenário foi atingido, porém acabamos esquecendo do comportamento posterior(Já estou logado, o que há de errado?). Listei alguns benefícios abaixo ao adotar esse critério.

Identificar um defeito

• Ao implementar validações assertivas na automação do seu cenário, irá permitir que você identifique defeitos mais rapidamente, tanto da funcionalidade a ser validada, quanto de outras correlatas.

Validação precisa

• Temos que tomar cuidado para não criar scripts com falsos positivos, devemos fazer o máximo de validações possíveis e não só garantir que o texto está presente na tela, mas também validar elementos que estão envolvidos no cenário de maneira direta e indireta.

Garantia da Qualidade

• Ter uma suíte de testes confiável dentro de uma regressão estabelece um padrão de qualidade da aplicação, evita manutenções futuras e cumpri o papel da garantia da qualidade.

# Como saber se estou fazendo validações assertivas? 💡

• Entenda a funcionalidade como um todo, verifique comportamentos posteriores de uma requisição, abuse nas validações de elementos relacionados ao cenário, textos na página podem mudar facilmente, o que pode causar a manutenção contínua do seu código e por fim, utilize bibliotecas de apoio para melhorar as suas validações.

A Inveja de identificar elementos por Full Xpath

Keep Calm & deixa de recalque!

Eu aposto que no seu primeiro contato com automação de testes você utilizou um Full Xpath para interagir com elementos WEB/Mobile, certo? Muitos treinamentos gratuitos na internet utilizam de forma incansável o Xpath como o localizador principal. Nada contra o Xpath, é um ótimo meio de mapear elementos, mas você deve usa-lo de maneira adequada. Por que não usar Full Xpath?

Fragilidade da automação

• Full Xpath é basicamente um caminho direto que carrega nele toda estrutura DOM até o elemento final que você deseja mapear, dentro dessa estrutura pode conter propriedades dinâmicas ou simplesmente uma lista que pode ser atualizada, tornando a automação frágil para qualquer mudança na página.

Manutenção

• Uma estrutura de elementos que muda com facilidade causa uma manutenção frequente no seu projeto, fazendo com que gaste tempo corrigindo seus cenários, atrasando a entrega da funcionalidade.

# Sugestão 💡

• É claro que existem excessões referente ao Full Xpath, mas o ideal é você utilizar o xpath contendo propriedades seguras, que não irão mudar com frequência. Tem um site que trás bons exemplos de como montar seu Xpath de forma mais robusta. E claro, utilizar propriedades seguras como ID e Classes.

A Preguiça de não indentar o código

Não estamos falando só de tab

Manter o código indentado não é só questão de estética, sabemos que linguagens como Python não permite a execução do programa se o código não estiver devidamente tabulado. O tab é maneira mais simples de indentar suas funções, porém há outras maneiras de corrigir esse problema, veja a seguir.

Legibilidade

• De fato fica muito mais fácil entender funções que estão alinhadas no seu programa e por mais que tenha linguagens que funcionem sem a exigência de indentação, crie o hábito de tabular para facilitar a leitura do coleguinha que também vai mexer no mesmo projeto.

Funcionamento

• Como mencionei a acima, existem linguagens que não funcionam sem a tabulação, isso se aplica a Classes, Atributos, Métodos, Variáveis e até para importar uma biblioteca, fique atento para não perder um bom tempo do seu dia debugando código.

# Dicas 💡

• Para facilitar o alinhamento do seu código, utilize também extensões disponíveis no seu editor de texto e bibliotecas para a validação estática do código fonte, para apontar possíveis ofensas no seu projeto.

A Ira de não documentar as Dependências

Na minha máquina funciona

É muito comum instalar uma dependência para resolver um determinado problema e acabar esquecendo de adiciona-lá ao seu gerenciador de pacotes posteriormente, causando ira nos seus pares de projeto. Veja como evitar esse tipo de problema.

Documentação

• Listar todas as dependências do projeto faz parte da documentação do software, então sim, deve ser registrado com muito cuidado para não entregar para o sue cliente um produto incompleto.

Funcionamento

• Ao não adicionar dependências requeridas do seu projeto você compromete o funcionamento da automação em um ambiente externo, por exemplo ao executar seus testes regressivos em um servidor durante o pipeline de deploy.

# Dicas 💡

• Encare as dependências do seu projeto como parte da documentação, registre todas em uma ferramenta de gerenciamento de projetos e não se esqueça de inclui-lá em seu gerenciador de pacotes e remove-lá caso não tenha mais utilidade.

Resumo

• O objetivo desse artigo é apresentar para vocês boas praticas de programação e automação de testes, fazendo uma brincadeira com os 7 Pecados Capitais, mas pegando no pé de todos nós que temos esses vícios. Tudo o que foi dito acima pode ser aplicado a qualquer framework/linguagem, por isso não trouxe exemplos práticos, pois iria deixar o artigo muito extenso. Espero ter ajudado você com essas dicas. Até!!!

Fonte Gifs: https://giphy.com/explore/brasil