Arquitetura e engenharia em automação E2E

7 min readAug 1, 2023

Esse texto é a transcrição de uma apresentação que fiz no TDC Future, de dezembro de 2021.

Imagem com o texto falando sobre a palestra, no horário das 12:00 às 12:45 — Atrapalhando o almoço das pessoas!

Imagine a situação: você acaba de entrar em uma empresa com a missão de automatizar testes E2E, pois a empresa não tem esse tipo de automação. Então você se faz a primeira pergunta:

Qual framework ou ferramenta que eu devo usar?

Porém, essa é uma pergunta incorreta a se fazer. Melhor, é a pergunta que não se deve fazer no primeiro momento, pois está diretamente enviesada com o seguinte pensamento:

A AUTOMAÇÃO DE TESTES É APENAS FERRAMENTA OU FRAMEWORK.

E esse pensamento é extremamente comum, uma vez que quando buscamos por “automação de testes” os resultados são voltados a ferramentas ou frameworks.

E quantas comunidades e pessoas têm seus frameworks de estimação? Frases como essas abaixo são irreais, mas podemos claramente ver pessoas dizendo:

Ei, psiu! Você já ouviu a palavra de Cypress hoje?
API’s no céu, RestAssured no teste! É para glorificar de pé!
Se aliste no exército do Capybara, torne-se um soldado
Que tal ser vegetariano e usar Cucumber?
Selenium e JUnit proverá tudo que precisamos. Venha conosco!
Não se torne um soldado, se torne um lutador na escola do Karate DSL!

Então o que devemos ter em mente quando falamos de automação de testes, além de frameworks? Como podemos agregar valor ao meu contexto?

Garantindo a cobertura dos cenários mais críticos da aplicação

Definir quais são os cenários mais críticos da aplicação e priorizar a automação é uma peça chave para que sua automação agregue valor!

Não adianta nada automatizar 5 mil casos de testes, sendo que 100 casos mais críticos estão sendo feitos manualmente e levando duas semanas para serem feitos manualmente.

Além disso, escolher se vai automatizar frontend ou o backend pode trazer benefícios: se a empresa quer simular a interação do usuário de ponta a ponta, então automatizar os testes usando front end. Agora se o que traz valor são os cenários críticos visando regras de negócio, pode ser uma boa automatizar o backend. O motivo é o custo da automação em ambos lugares: no frontend, a automação tende a ter mais custo para se manter, por conta das mudanças constantes de layout, etc, enquanto backend tende a ser mais estável.

Outra consideração é levantar os cenários de maior risco para aplicação, ou pelo menos um cenário crítico positivo e um negativo.

Por exemplo, um app bancário e queremos automatizar a transferência de dinheiro: é um risco altíssimo não ter ele funcionando, então podemos automatizar todos os cenários de riscos que envolvem transferência. Ou a área de negócio entende que apenas um cenário que valide que funcione a transferência (cenário positivo) e outro que não funcione por falta de saldo em conta (cenário negativo) seja de valor.

Não depender de processos manuais

Quando estamos criando uma automação E2E geralmente pensamos em apenas na automação das telas, API’s, no fluxo entre telas, etc. E depois temos que ficar criando massas de dados para automação ser executada, e nós mesmos termos de rodar a automação localmente. Então por que não automatizamos esses dois pontos também?

Gerar massas de dados para testes pode tomar um bom tempo da pessoa que está testando e executando os testes automatizados. Já vi casos do teste levar 5 minutos, mas a massa ficar pronta após 3 dias.

Além, claro, que automações executadas localmente faz a necessidade da pessoa, ou das pessoas, que desenvolve a automação ficar de plantão quando o time desenvolve uma nova feature e quer que seja executada a automação, para ver se a nova feature atrapalhou algum fluxo que não deveria.

Então automatizar a geração de massas de dados e colocar a automação em uma pipeline para ser executada, seja a cada X horas ou a cada nova subida no ambiente, garante ainda mais efetividade da automação.

Ter um código flexível e manutenível

Este aqui é um desafio enorme entre desenvolvedores quando estão criando seus códigos, pois querem que a manutenção e a inclusão de novas funcionalidades seja o mais fácil possível e não altere o fluxo que não deve ser alterado.

E para ter isso podemos usar de:

Código com alta coesão e baixo acoplamento
Não engessar os componentes em comum
Código de fácil entendimento
Conhecer os principais recursos da linguagem

E também podemos usar das boas práticas de desenvolvimento de software:

DDD
S.O.L.I.D.
DSL
Design patterns
Etc

Que seja fácil e rápido a identificação das falhas dos testes

Durante a codificação coloquem logs para identificar o passo a passo de cada etapa que o teste fez, pois caso aconteça um erro vai ser fácil de identificar e resolver se não houver informações suficientes do motivo do erro.

É aquilo:

NO LOGS, NO CRIMES!

E também fazer a integração entre a automação e o sistema de gestão de testes ou histórias, caso a automação esteja rodando em uma pipeline.

Integração com o sistema de gestão
Jira / Zephyr
Mantis
Trello
Azure
Sistema da empresa

Pois com isso, ao falhar o teste por algum erro vai ter o report do mesmo registrado no sistema e quem for dar manutenção vai saber o que aconteceu.

O resultado dos testes devem sempre ser os mesmos, com as entradas atendendo as mesmas condições

Se eu crio um novo usuário para o sistema e ele precisa de um certo valor em conta, o resultado do teste deve ser o mesmo quando for feita a transferência. Então prestar bastante atenção nesse ponto, pois acontece muito de ficarmos mais atentos a massa em si e as informações que elas têm do que suas características. Assim temos testes cada vez mais confiáveis.

Faça uma prova de conceito para saber se está no caminho certo

Uma PoC é um pequeno passo no desenvolvimento de software, mas é um passo importante para saber se está no caminho certo.

Exemplo: escolhi Cypress pq javascript é lindo demais da conta!

Mas aí podem vir as dúvidas:

Será que realmente vale a pena usar cypress onde o meu time é javeiro?
Será que o cypress é liberado pelo time de segurança?
Será que eu consigo colocar o cypress na pipeline?
Tenho o conhecimento o suficiente em Javascript para criar um código flexível e extensível, para que lá na frente eu não sofra?

Então antes de sair colocando um framework, ou qualquer outra coisa dentro da automação, faça um MVP, uma POC e prove sua teoria e seu valor. Mostre as áreas interessadas que vai dar certo.

Lembre-se: automação E2E requer muito esforço, logo dinheiro!

Com as dicas acima, podemos ter uma automação mais eficiente e que realmente agregue valor ao seu contexto. Que dê menos trabalho quando formos dar manutenção. Estar atento às técnicas e teorias da engenharia e arquitetura de software podem trazer vantagens para sua automação.

E fica aquela dúvida:

Como vamos falar sobre qualidade de software sendo que o que estamos desenvolvendo na automação E2E não possui?

Aqui fica uma recomendação de leitura, que é o livro Lessons Learned in Software Testing. É um livro que está fazendo 20 anos, mas é bem atual. E em uma das lições é falado:

AUTOMAÇÃO DE TESTE É UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE.

E eu concordo plenamente com ele. Trabalho com TI desde 2009 e quando comecei a trabalhar com qualidade, principalmente automação E2E, via todas similaridades com o processo de desenvolvimento de software.

Pensem só: uma automação temos código, pipeline, code review, execução de código, consumir API ou outra fonte para os dados, e por ai vai… tem pé de pato, bico de pato, rabo de pato, faz quack quack, então é um pato!