Ir para o conteúdo

Framework padronizado de Automação de Testes

4 min. de leitura

Avatar de Adriano Fantinelli

Adriano Fantinelli Autoria do conteúdo


Com a criação e o desenvolvimento de um projeto de Automação de Testes, muitos desafios podem surgir. A dificuldade fica ainda maior quando estamos tratando de uma equipe composta por vários times que desenvolvem um mesmo produto.

Este cenário mais complexo é justamente o que ocorre no nosso atual projeto. Assim, para auxiliar as equipes da estrutura de nosso cliente, desenvolvemos uma solução, criando um framework padronizado para Automação de Testes.

Nos próximos parágrafos, contaremos um pouco do que nos motivou a desenvolver este framework, vantagens que foram agregadas, dificuldades que encontramos e um pouco da estrutura do mesmo.


Cenário atual

  • A estrutura do cliente possui diferentes squads, onde cada squad seguia uma estrutura de Automação de testes diferente. Porém, todas trabalhando em partes distintas da mesma aplicação, e por isso tendo muitas interdependências.
  • Cenários de testes manuais estavam sendo escritos sem um padrão para a ferramenta de testes automatizados.
  • A estrutura do gerenciamento de cenários, dos ciclos e dos planos de testes não estava bem definida.

Workflow de Qualidade:

Workflow de Qualidade

Necessidades a serem atendidas

  • Fomentar o engajamento dos QAs quanto à utilização da Automação de testes com a cultura DevOps em CI/CD.
  • Evoluir um modelo de ambientes separando quais testes serão executados em cada um via Automação de Testes.
  • O novo framework precisava atender a algumas premissas:
    • Estar amarrado a um processo fluido, no qual permitisse aplicação de estratégia de cobertura por camadas, e integração com a ferramenta de gerenciamento de testes (plugin Zephyr para o Jira).
    • Ter reaproveitamento de código entre as squads (ex.: para alguns cenários, squads dependem de massa gerada por outras).
    • Facilitar o trânsito dos QAs pela estrutura, o aprendizado e compartilhamento de conhecimento com os novos, já que todos conhecem e atuam com a mesma tecnologia.

Modelo proposto de Processo:

Modelo proposto de processo

A partir do modelo proposto, destacamos as seguintes evoluções para atender às necessidades do cliente:

  • Integração da Automação de Testes com a ferramenta de gerenciamento de cenários de teste, com reaproveitamento total dos cenários já escritos em Gherkin na fase de análise. Gerar maior visibilidade dos cenários e planos de teste executados, bem como trazer os resultados da automação diretamente para dentro do plugin de teste sem precisar da intervenção do QA, complementando os relatórios e facilitando a geração de métricas.
  • Padronização e ganho de tempo com o desenvolvimento, havendo uma estrutura pronta para uso com a integração com diferentes ferramentas, tais como, banco de dados, relatórios de execução e ferramentas de CI/CD.
  • A estrutura pode ser aplicada para qualquer linguagem de programação desde que utilize um framework compatível com Gherkin.
  • Funções que são utilizadas por mais de uma squad podem ser compartilhadas, como exemplo, a funcionalidade de login ou navegação no menu.
  • Fomenta boas práticas de projeto e desenvolvimento de Automação de Testes.
  • Evolução da régua técnica das equipes.
  • Facilitação da geração de massa de teste.
  • Facilitação cross na manutenibilidade do projeto, permitindo que todos os colabores da estrutura, independente da squad, possam auxiliar no Framework.

Dificuldades e desvantagens

Durante o desenvolvimento do Framework encontramos algumas dificuldades na integração com a plataforma atual que gerencia os planos de teste do cliente. Entre elas, bug de contrato e constante expiração da autenticação. E, como medida resolutiva, acionamos a empresa para correção.

Além destas dificuldades, foi possível notar que teríamos algumas desvantagens ao realizar esta padronização. Como exemplo temos uma maior preocupação e esforço em manter as funções compartilhadas sempre atualizadas. Também foi possível identificar a dependência com a linguagem de implementação realizada em JavaScript, dificultando a implementação do framework em outras linguagens.

Estrutura do projeto:

Estrutura do projeto

A imagem acima apresenta a arquitetura do framework desenvolvido. O fluxo inicia com a criação do Plano e cenários de teste no Zephyr Scale, ferramenta utilizada para realizar o gerenciamento de testes. Seguindo, temos a Automação de testes, para a qual optamos por padrão em utilizar a ferramenta do Cypress.

Dentro desta estrutura da Automação de testes, disponibilizamos Camadas base que são Integrações, UI e API. Partindo para a parte de UI e API, ambas são utilizadas na estrutura do Cucumber que, por sua vez, utiliza dentro de seus Steps os padrões Page Object e Custom Commands. Estes padrões permitem que Utils sejam geradas com a proposta de fornecer ao usuário uma facilitação na implementação de novas funcionalidades, proporcionando ganho de tempo já que não haverá esforço em desenvolver o que há em comum entre os projetos das equipes.

Entrando na camada base de Integrações, implementamos o CI/CD utilizando a ferramenta GitHub Actions. Por ele conseguimos executar os nossos testes, gerar relatórios das execuções, e disponibilizar uma GitHub Page para mostrar as informações da execução geradas através do Allure report. Entrando na parte de Relatórios, temos o Allure report, comentado anteriormente, e o Cypress Dashboard, uma ferramenta específica para a geração de relatórios com o Cypress.

Outras integrações implementadas são a de Bancos de Dados Mongo e SQL, estas detêm toda a estrutura de conexão com as bases prontas e também disponibilizam queries de uso comum entre equipes, como, por exemplo, a consulta de pedidos, contribuindo assim com a camada Utils.

Por fim, há a integração com o Zephyr Scale. Nessa parte, as informações das execuções passam para Ciclos de testes e estes, automaticamente, são inseridos no plano de teste na plataforma Web.

Conclusão

Foram expostas acima motivações, vantagens, dificuldades e a estrutura de nosso projeto. Este Framework proporciona diversas facilidades para os QAs de nossa estrutura, e esperamos que o mesmo possa servir de auxílio para o seu projeto.

Verificou-se que ao existir um Framework padronizado de Automação de Testes diversos benefícios são gerados. Entre eles, o desenvolvimento da integração da ferramenta de gerenciamento de testes com o Confluence, nossa ferramenta de documentação, e também a integração dos testes unitários com o Zephyr, melhorando nossa visualização da cobertura da aplicação. Os benefícios impactam diretamente na qualidade e entrega do processo de Automação de Testes dentro de uma estrutura com diversas equipes atuando no mesmo produto.

Autores: Adriano Fantinelli e Maristela Oliveira de Paula.

Gostou?