Como escolher um framework de automação – fazendo uma POC (Proof of Concept)

É muito comum receber perguntas como “Playwright é melhor que Cypress?”, “Devo migrar de Selenium pra Playwright?”, “O Playwright substitui o Robot?”.

A verdade para todas estas perguntas é: Depende.

Nenhum software é melhor que outro em um contexto isolado.

Se você tem uma suíte de 1000 testes rodando com Cypress e os testes são estáveis, a pipeline roda num tempo satisfatório para o projeto, e o time é produtivo, você TALVEZ não precise mudar de framework para um “mais moderno”.

Na tecnologia, sempre vai ter algo “melhor” disponível a todo momento. Mas melhor pra quem? Melhor comparado a quê? É sempre bom acompanhar as atualizações de frameworks, práticas e metodologias, mas ao mesmo tempo tomar decisões inteligentes para construir soluções que sejam duradouras para os times.

Existe um curso (grátis) da Angie Jones sobre como criar uma boa base para automação e um dos tópicos é como escolher o framework (importante falar que não é só isso, tá?!). E partindo desse curso eu compartilho aqui com vocês um modelo de POC que funcionou muito bem para mim.

Queria lembrar aqui também que: o uso da IA deve ser utilizado com MUITA moderação e sabedoria aqui pois ela pode oferecer resultados incompletos ou desatualizados. Consulte sempre a documentação oficial mais atualizada dos frameworks.

Primeiro vou compartilhar meu cenário para que vocês entendam um pouco o meu processo com a POC:

Eu era Quality Engineer Lead e fui contratada para criar um time de qualidade na empresa, não haviam outros QEs. Tinham vários projetos, e o que eu fui designada como prioridade tinha o front em react com JavaScript migrando para TypeScript e não tinha nenhum teste e2e. O back era em PHP os devs eram full-stack. Eles estavam todos confortáveis em desenvolver em JavaScript e/ou TypeScript.

Pessoalmente, eu considero importante selecionar um framework que suporte uma linguagem que os devs tenham familiaridade, pois podem ajudar com dúvidas técnicas de programação e code review. Além disto eu gosto de adotar um modelo de trabalho onde os devs tenham a liberdade de implementar ou dar manutenção nos testes. Desta forma, se a empresa não puder contratar um número ideal de QEs (ou qualquer outro motivo), podemos mesclar o time e garantir o sucesso da automação com os QEs fazendo papel de “mentores de qualidade” ao invés de “garantidores de qualidade”. E tem outros motivos também, mas vamos manter o foco do artigo.

POC Passos:

1. Identificar o motivo da escolha do framework

Se o time não tem nenhuma automação, eu considero mais fácil, pois você precisa apenas listar o que é importante que o framework suporte.

Se o time já tem automação, é importante identificar o motivo da mudança de framework. A automação está flaky? Está complexa a manutenção? Está lenta para executar? Falta ambiente de testes?

Este passo é importante pois vai guiar a lista do próximo passo. As vezes o projeto só precisa de um refactoring para solucionar problemas como flakiness ou manutenibilidade ou integrar uma biblioteca mais nova para resolver algum problema específico de relatório ou paralelização na pipeline.

Recomendo envolver profissionais de outras áreas como DevOps e Arquitetos da empresa para ajudar a buscar uma solução efetiva para o problema. Se isto não for possível, eventos de tecnologia são ótimas fontes de conhecimento, vários profissionais compartilham como resolveram problemas, pode ser que alguém tenha feito algo semelhante e possa te direcionar melhor.

Em ambos os casos, caso a decisão seja de adotar um novo framework, liste o que o framework precisa ter para resolver o problema do projeto, por exemplo (são só exemplos, não necessariamente precisa ter todos):

suporte a uma linguagem específica ou a múltiplas linguagens (caso precise fazer alguma migração futura) – Playwright por exemplo oferece suporte para NodeJs, Python, Java e .Net, mas as linguagens não possuem as mesmas funcionalidades)
suporte a teste multi browser
boa variedade de selectors e de forma amigável
arquitetura flexível (pode usar POM ou não, pode criar comandos customizáveis)
Paralelismo nativo
integração com API (para mockar third parties or interceptar serviços)
suporta cloud testing (BrowserStack, LambdaTest, SauceLabs, etc)
suporta teste de regressão visual
oferece relatórios de testes
suporte a acessibilidade
suporte a performance (web e API)

2. Listar os frameworks avaliados

Neste passo, vamos identificar frameworks que resolvam o máximo dos problemas que listamos no passo 1.

Eu recomendo informar o time e os times próximos para colher sugestões de frameworks existentes e não apenas ir no que você já conhece. Pesquise também os frameworks mais usados, mais recentes, etc.

Se for necessário, faça uma votação simples com os frameworks sugeridos e selecione 4, no máximo 5 para fazer uma primeira avaliação; neste passo é necessário apenas ler a documentação principal e entender como o framework está se comportando. Observe os seguintes pontos:

o GitHub do projeto e ver quantas estrelas tem
a quantidade de releases e a frequência
a quantidade de bugs
o npmtrends
o suporte da comunidade

Após entender o que cada framework oferece, simplifique a lista para 2, no máximo 3 para implementar a POC.

3. Escolher o que será implementado

Diante da natureza do seu projeto, escolha uma funcionalidade que seja simples (para que você não gaste muito tempo), e ao mesmo tempo que englobe pelo menos 1 ou 2 das características principais do seu projeto, envolva seu Product Manager para ver talvez qual a funcionalidade mais usada do sistem por exemplo:

Login e Cadastro de produto
Busca de produto e Compra

Enfim, isto vai variar bastante, mas a ideia aqui, é testar quão fácil é para utilizar os recursos do framework em aquilo que você fará mais na aplicação. Muitas vezes só um login não retratará tudo. Ao mesmo tempo, não escolha uma funcionalidade muito complexa pois a POC tem que ser relativamente rápida. Eu diria de 1 a 2 semanas seria o ideal, dependendo do projeto e do tempo que você terá para dedicar (as vezes você terá apenas 1 ou 2 dias ¯\_(ツ)_/¯ ).

4. Definir os critérios avaliados

Nesta etapa é importante fazer uma conexão com o que foi listado na etapa 1 “motivo da escolha do framework”. Se você está buscando um framework que rode mais rápido, performance deve ser um critério. Porém lembre-se de que existem critérios que são combinados; por exemplo performance também se atinge com paralelização. Então a definição dos critérios, não deve ser uma atividade fria. Existem critérios objetivos e também critérios subjetivos (combinados). Explore esta etapa com muita sabedoria.

Alguns critérios que eu costumo avaliar são:

suporte a linguagens (dependendo da expertise do time corrente e também da facilidade de encontrar profissionais no mercado)
performance (para implementar, executar, debugar, atualizar, gerar relatório)
paralelismo (não só por arquivo, mas por teste dentro do arquivo)
variedade de selectors (principalmente suporte a user facing selectors e auto-waiting)
arquitetura flexível
suporte a interações com APIs (mock de third parties e interceptação de requests)
suporte a mobile (ou integração com outros frameworks modernos)
suporte a cloud testing
simplicidade de instalação e uso
objetividade da documentação (quanto tempo você gasta para achar uma informação)
suporte a identificação de falhas (possui relatórios?, os erros são claros no console?, apresenta trace? apresenta screenshot? apresenta vídeo?)

Você deve decidir junto a seu time quais critérios serão adotados e como será a avaliação de cada um deles.

5. Implementar o código nos frameworks escolhidos

Faça a instalação do zero dos frameworks escolhidos e implemente os cenários definidos.

É extremamente importante nesta etapa já começar a avaliar este processo, mesmo que este não seja um critério definido. O dia a dia do seu time será implementando novos testes, portanto é importante que a implementação seja simples.

Observe com atenção tudo que você fizer nesta etapa:

quantos pacotes/bibliotecas externas você precisa instalar
qual o tempo de instalação (do framework em si e das bibliotecas extras)
qual o tempo para achar orientações na documentação
o quanto você pode usar configurações globais no arquivo de configuração
o quanto você precisa escrever nos arquivos de teste (e repetir informações em diferentes arquivos)
a facilidade de ir escrevendo e rodando o teste
quão simples é para entender os erros durante o processo de implementação

6. Preencher os critérios de avaliação

Normalmente eu começo esta etapa assim que os critérios estão definidos. Vou preenchendo a medida que vou fazendo as coisas, nunca deixo tudo para o final. Aqui eu uso uma planilha do excel/sheets com as notas/comentários de cada critério por framework. Simples e objetivo. O time deve confiar em quem está fazendo o processo sem a necessidade de ficar justificando cada etapa do processo com excesso de detalhes/informações.

É normal adicionar e remover critérios durante o processo, é normal dar uma nota e depois mudar a nota. É realmente um processo cíclico e interativo.

Se tiver fazendo a POC com mais pessoas, é muito importante que seja alinhada o forma de avaliação, conversem como irão dar as notas e tentem achar algo em comum para calibrar as pontuações. Pessoalmente prefiro fazer POCs de framework individualmente para que haja o mínimo de ruído.

É legal também conversar com algumas pessoas apresentando parte do processo para ver se tem algum ponto que você não tenha observado. Considere alguém que você confia e também esteja preparado para descartar sugestões e opiniões que você julgue não válidas para o seu contexto.

7. Montar uma DMF e enviar para avaliação do time

DMF (Decision Making Framework) é uma metodologia que fornece um detalhamento de cada critério de avaliação contribuindo para tomada de decisões de forma colaborativa e com comunicação clara entre os influenciadores de decisão e suas equipes.

Se optar por usar este formato, comunique a todos envolvidos (incluindo líderes e times impactados) que este processo será adotado. Uma outra alternativa menos disruptiva e mais tradicional é montar uma apresentação com os resultados e convidar os envolvidos. Eu prefiro o modelo de DMF pois gera mais envolvimento e participação levando a exercitar autonomia e engajamento dos membros.

Eu uso Notion ou o próprio excel. Também da pra fazer no Confluence. Dependendo das ferramentas que você usa no trabalho, monte um documento com as informações abaixo (e o que mais você achar importante).

Existem vários formatos, eu tenho usado algo assim:

Visão geral: o que está sendo feito e qual o objetivo dessa DMF. Bem resumido. O leitor deve ser capaz de entender se essa DMF é de interesse dele ou não.
Contexto: visão detalhada da atividade. O motivo desta decisão, o impacto e links para discussões prévias ou números que levaram a esta necessidade.
Processo de avaliação: explicar como está sendo feito (se uma ou mais pessoas), os critérios que serão avaliados e links para o documento com as notas e para os repositórios com código fonte.
Prós e Cons de cada framework: Nesta etapa, eu procuro já destacar o framework que obteve a maior pontuação para justificar a tomada de decisão. O trabalho já foi feito, o documento é para que o time entenda o que foi realizado e levante algum risco que não foi considerado. Inclua screenshots e alguns números que se destacaram significativamente.
Proposta: Em uma frase, qual a decisão que precisa ser tomada. Ex: “Adotar o framework Playwright como ferramenta de automação de UI e API para o projeto Death Start.”.
Votação: Adicione as pessoas que devem ser envolvidas nesta decisão. Líderes, Novas Contratações, Estagiários, DevOps, Desenvolvedores, Engenheiros de Qualidade, Time de Suporte. Inclua entre 3 a 7 pessoas que façam sentido.
Data limite para votação: Geralmente 1 semana após a criação da DMF é suficiente. É possível marcar conversas para discutir alguma parte que não tenha ficado clara para que o voto de uma pessoa seja definido. Também é possível que caso alguma pessoa vote contra que seja conversado até que a pessoa se sinta confortável em concordar com a proposta. Ou em caso de empate é possível nomear alguma pessoa para tomar a decisão final.
Decisão: O que foi decidido (a ser preenchido quando o período de votação é finalizado).

O objetivo desta etapa é decidir oficialmente o framework adotado.

Exemplo de uma DMF que fiz para avaliar Playwright vs Cypress.

Conclusão

Através destes passos, é possível tomar decisões adequadas para todo o time de desenvolvimento, proporcionando visibilidade para o trabalo do time de qualidade e aproximando as áreas que são impactadas por este processo.

Lembre-se de criar uma estratégia de comunicação recorrente sobre o status da implantação do novo framework e os resultados atingidos. Além de acompanhar a liberação de novas versões do framework e aproveitar as melhorias, mantendo a versão sempre que possível atualizada.

Referências Complementares

Playwright: https://playwright.dev/

Batalha de Código Cypress vs Playwright no Minas Testing Conference 2023: https://testingwithrenata.com/portfolio/minas-testing-conference-2023/

Respondendo as perguntas da Batalha de Código:
Parte 1: https://testingwithrenata.com/portfolio/youtube-live-mtc-2023-parte-1/
Parte 2: https://testingwithrenata.com/portfolio/youtube-live-mtc-2023-parte-2/