Estudo de viabilidade de automação de testes de uma aplicação web.

Olá querido(a) leitor(a)!

Estou aqui para compartilhar com você meu aprendizado sobre Testes Automatizados, onde realizei esse estudo para dar início aos testes automatizados de uma aplicação web da empresa em que trabalho.

Photo by Hello I'm Nik on Unsplash

Minhas principais fontes de estudo, que foram:

• Curso de Java básico pela Alura;
• Curso de Jenkins e Docker pela Alura;
• Curso de Git e Github pela Alura;
• Curso de Selenium pela Alura;
• Curso de Cypress pela Udemy;
• Curso de Robot Framework pela QA Ninja;
• Vídeos do Júlio de Lima no Youtube;

O que vem antes da automação de testes?

Antes de sairmos automatizando tudo ou qualquer coisa, precisamos pensar em algumas características muito importantes, que são elas:

• Validação manual da aplicação;
• Criação automatizada do ambiente de testes;
• Preparação automatizada dos dados de teste;
• Definição da frequência e gatilhos de execução dos testes;
• Segmentação dos testes;

Validação manual da aplicação

Nesse ponto, precisamos ter a certeza de que certos fluxos da aplicação funcionam como esperado dado um determinado contexto. Pensando assim, aqui os testes manuais são muito importantes para comprovarmos que esses fluxos estão funcionando corretamente.

Dado um grupo de entradas e uma questão ambiental, ou seja, BD está em tal estado, a aplicação está em tal versão, a aplicação já está em pé.

O teste automatizado será uma espécie de contrato, ele vai dizer dado essas condições, a minha aplicação funciona como esperado.

Criação automatizada do ambiente de testes

Já aqui, devemos ter a construção do ambiente de testes de forma automatizada e versionada, senão sempre teremos que ter um ser humano pressionando o botão executar para que consigamos executar os nossos testes.

Preparação automatizada dos dados de teste

Nesse ponto, devemos ter a base de dados preparada de forma automatizada, para que na execução dos testes automatizados não tenhamos surpresas com os registros que iremos utilizar durante os testes. Exemplos: restore de banco, dump de banco de dados, entre outros.

Segmentação dos tipos de testes

É importante segmentar quais tipos de testes que queremos rodar. Podemos dividir os testes em:

• Pre-submit: nessa divisão se encontram os testes que serão executados antes da submissão do código, são testes que executam mais rápido. Exemplos: Unidade e Integração.
• Post-submit: nessa divisão se encontram os testes que serão executados depois da submissão do código, são testes que demoram mais pra executar. Exemplos: Aceitação Web, Aceitação Mobile, Regressão Visual, entre outros.
• Smoke: eles são executados dentro da divisão Post-submit. Nessa divisão estão os testes mais importantes da aplicação. Por exemplo, temos um total de 100 testes no Post-submit, porém no primeiro momento iremos rodar 20 testes, os mais importantes, esses 20 testes são os Smoke Tests.
• Regressão: também executados dentro da divisão Post-submit. Olhando para o nosso exemplo anterior, são os outros 80 testes que restaram e que precisam ser executados para validar que toda a aplicação continua funcionando conforme o esperado. Como são testes mais demorados, eles podem ser executados em um momento apartado de uma Sprint, por exemplo.

Definição da frequência e gatilhos de execução dos testes

Para esse ponto, devemos definir os momentos certos em que os testes serão executados, sejam eles os testes Pre-submit, Post-submit e Regressão.

Por exemplo, todas as vezes que um desenvolvedor alterou um trecho de código e tenta submeter esse código para que ele seja mergeado, é disparado um mecanismo de execução automatizado com esse pacote de testes, que são os testes Pre-submit. Se os testes passarem, então o código é mergeado e os testes Post-submit são chamados.

Então já que sabemos o que devemos fazer antes de sair “codando” vários testes, vamos conhecer um pouquinho as 10 principais camadas para automatizar testes:

1. Unidade: nessa camada estaremos olhando para um objeto, que pode ser um método que pertence a alguma classe ou uma função, onde iremos pegar essa pequena parte do software, isolar de suas dependências externas e criar um ambiente para que possamos simular ou utilizar esse determinado pedaço, validando se o mesmo funciona corretamente.
2. Integração: nessa camada estaremos integrando elementos da aplicação para validarmos seu correto funcionamento, ou seja, aquele método ou função que isolamos nos testes de Unidade, agora iremos trazer suas dependências para validação.
3. Componente: nessa camada os testes estão voltados a Frontends modernos, onde conseguimos desacoplar o componente dessa aplicação e validar seu comportamento de forma isolada, sem precisar abrir algum navegador ou algo do tipo.
4. APIs Rest: nessa camada enviaremos requisições para as APIs Rest e validaremos se a resposta de cada API está de acordo com o esperado, validando os dados do corpo da resposta, o status code, a mensagem recebida, o tempo que levou para retornar a requisição, entre outros. Podemos utilizar o JUnit para escrever esses testes.
5. APIs SOAP: nessa camada enviaremos requisições para as APIs SOAP e validaremos se a resposta de cada API está de acordo com o esperado, validando, por exemplo, os valores de um XML que é o documento que trafega dentro das comunicações dentro dessa camada. Podemos utilizar o JUnit para escrever esses testes.
6. Regressão Visual: nessa camada os testes olharão para a estrutura visual da página e tentarão identificar, baseando-se nas regras que definimos, se a aplicação está sendo renderizada da maneira apropriada. Um framework bem conhecido é o Galen Framework.
7. Aceitação Web: nessa camada os testes estão mais voltados ao que um usuário real faria com a aplicação web, ou seja, temos um fluxo, um caminho que esse usuário faz e que podemos nos basear . Conhecendo esse fluxo, iremos mapear os elementos que iremos navegar e interagir, e assim validamos se as saídas que foram apresentadas estão de acordo com o esperado. Algumas das ferramentas mais conhecidas são Selenium WebDriver, Cypress e Robot Framework.
8. Aceitação Mobile: nessa camada os testes estão mais voltados ao que um usuário real faria com a aplicação mobile, ou seja, temos um fluxo, um caminho que esse usuário faz e que podemos nos basear . Conhecendo esse fluxo, iremos mapear os elementos que iremos navegar e interagir, e assim validamos se as saídas que foram apresentadas estão de acordo com o esperado. Uma ferramenta bem conhecida é Appium.
9. Aceitação Desktop: nessa camada os testes estão mais voltados ao que um usuário real faria com a aplicação desktop, ou seja, temos um fluxo, um caminho que esse usuário faz e que podemos nos basear . Conhecendo esse fluxo, iremos mapear os objetos que iremos utilizar e interagir, e assim validamos se as saídas que foram apresentadas estão de acordo com o esperado.
10. Performance: nessa camada podemos automatizar a simulação do envio de requisições do cliente para o servidor de forma simultânea e a quantidade de vezes que for necessário, onde por fim analisamos os resultados dessas requisições para descobrir como a aplicação se comporta em dada situação. Uma ferramenta bem conhecida é o JMeter.

Então a minha escolha para esse momento será a camada de Aceitação Web, onde decidi estudar 3 ferramentas para atender esse meu objetivo: Cypress, Selenium WebDriver e Robot Framework.

O que é Cypress?

De acordo com o site, Cypress é uma ferramenta de teste de Frontend de próxima geração desenvolvida para a web moderna. Abordam os principais pontos problemáticos que os desenvolvedores e engenheiros da qualidade enfrentam ao testar aplicações modernas.

Com Cypress é possível:

• Testes de configuração;
• Escrever testes;
• Executar testes;
• Testes de Depuração (Debug Tests);

Cypress é frequentemente comparado ao Selenium, no entanto, o Cypress é fundamentalmente e arquitetonicamente diferente. O Cypress não é limitado pelas mesmas restrições do Selenium, permitindo que você escreva testes mais rápidos, fáceis e confiáveis.

Site oficial: https://www.cypress.io/

Curso: https://www.udemy.com/course/testes-cypress/

O que é Selenium WebDriver?

De acordo com o site, O WebDriver conduz um navegador nativamente, como um usuário faria, localmente ou em uma máquina remota usando o servidor Selenium, marca um salto em termos de automação do navegador.

Selenium WebDriver refere-se às ligações de linguagem e às implementações do código de controle do navegador individual. Isso é comumente referido como apenas WebDriver.

Selenium WebDriver é uma recomendação W3C.

• O WebDriver foi projetado como uma interface de programação simples e mais concisa.
• WebDriver é uma API compacta orientada a objetos.
• Ele conduz o navegador de maneira eficaz.

Site oficial: https://www.selenium.dev/documentation/en/webdriver/

Curso: https://cursos.alura.com.br/course/selenium-testes-automatizados-aceitacao-java

O que é Robot Framework?

De acordo com o site, é uma estrutura de automação genérica de código aberto. Ele pode ser usado para automação de teste e automação de processo robótico (RPA).

O Robot Framework é aberto e extensível e pode ser integrado a virtualmente qualquer outra ferramenta para criar soluções de automação poderosas e flexíveis. Ser open source também significa que o Robot Framework é gratuito para uso, sem custos de licenciamento.
Robot Framework tem sintaxe fácil, utilizando palavras-chave legíveis por humanos. Seus recursos podem ser estendidos por bibliotecas implementadas com Python ou Java. O framework possui um rico ecossistema ao seu redor, consistindo em bibliotecas e ferramentas que são desenvolvidas como projetos separados.

O projeto Robot Framework está hospedado no GitHub, onde você pode encontrar mais documentação, código-fonte e rastreador de problemas. Os downloads são hospedados no PyPI.

O Robot Framework é independente do sistema operacional e do aplicativo. A estrutura principal é implementada usando Python e também é executada em Jython (JVM) e IronPython (.NET).

O próprio Robot Framework é um software de código aberto lançado sob a Licença Apache 2.0, e a maioria das bibliotecas e ferramentas do ecossistema também são de código aberto. A estrutura foi desenvolvida inicialmente na Nokia Networks e teve o código aberto em 2008.

Site oficial: https://robotframework.org/

Curso: https://qaninja.academy/curso/robot-beginner/

Minha experiência inicial com as ferramentas

A partir dos estudos realizados, decidi aplicar o aprendizado no Login do Ops Monitor. Essa é a visão dos arquivos gerados em cada uma das ferramentas, Cypress, Selenium e Robot, respectivamente:

Ferramentas de automação de testes

Cypress

Vamos dar uma olhada na estrutura de arquivos:

Estrutura de arquivos - Cypress

Automação do Login do Ops Monitor com Cypress:

Script de teste — Cypress

Selenium WebDriver

Vamos dar uma olhada na estrutura de arquivos:

Estrutura de arquivos - Selenium WebDriver

Automação do Login do Ops Monitor com Selenium WebDriver:

Script de teste — Selenium WebDriver

Robot Framework

Vamos dar uma olhada na estrutura de arquivos:

Estrutura de arquivos - Robot Framework

Automação do Login do Ops Monitor com Robot Framework:

Script de teste — Robot Framework

Minhas conclusões:

Sendo assim, minha ferramenta preferida para automação de testes da camada de Aceitação Web foi o Cypress, onde senti mais facilidade em manipula-lo e maior entendimento da linguagem que ele utiliza.

Aprendi que o mundo da automação de testes é muito maior do que eu pensava e que podemos aumentar cada vez mais a cobertura de testes, mas com cautela, para que o trabalho não seja perdido e seja realizado com qualidade para que todos do time possam usufruir da melhor forma possível.

Com todo esse conhecimento adquirido, irei compartilhar com meu time minhas ideias iniciais e iremos colocar em prática a automação dessa camada.

Obrigada por chegar aqui! :D