Tech Chat – Playwright para iniciantes – diretamente da Suécia com Helen Galan

Neste Tech Chat, recebi a Helen. Ela é uma profissional com uma experiência muito rica fora do Brasil. Ela se formou na Suécia e atua com desenvolvimento e testes. Ela nos conta sobre a sua experiência com Playwright sendo iniciante na ferramenta. E esse Tech Chat ficou muito legal pois adiciono algumas dicas que podem ser úteis para outros iniciantes.

Helen, esse é um dos meus Tech Chat favoritos! Parabéns pela determinação e obrigada por compartilhar sua experiência.

1. Conte-nos um pouco sobre você e o projeto que trabalha com Playwright.

Helen:
Nasci em São Paulo e moro na Suécia, Nyköping faz quase 6 anos. Sou QA faz 4 anos e recentemente me tornei Desenvolvedora Junior. O que eu mais gosto é aprender o sistema e descrever os testes. O que menos gosto é não ser ouvida ou ser vista como “a apontadora” de falhas humanas.
O projeto é um site de ticketing, o projeto em si é pequeno mas nosso sistema é enorme. Usamos C# e hoje somos 10 pessoas, mas muda bastante. Não trabalho com outros QA’s no momento, mas existe o pensamento para nos aproximar mais com a equipe dos Estados Unidos. Fazemos em torno de 1 release a cada duas semanas, podendo variar.


Renata:
Muito legal Helen! Parabéns pela jornada! Já quero ir te visitar na Suécia :).
Interessante quando você fala “O que eu mais gosto é aprender o sistema e descrever os testes”, isso me lembra muito o início da minha carreira. Ao longo do tempo, percebi que hoje eu me dedico muito mais a aprender técnicas de teste do que o sistema em si. Aprender o sistema é fundamental tá?! Não me entenda mal. Acontece que, em muitas situações, não há tempo pra aprender o sistema como um todo, e você precisa entregar do mesmo jeito. Minha perpectiva é que cada vez mais, as demandas serão de “como testar” ao invés de “o que testar”. Eu sou muito a favor do compartilhamento da responsabilidade da qualidade, o que significa que todo o time deve ser apto e responsável para fazer testes; o papel da pessoa de qualidade, se direciona mais a uma pessoa que direciona e ensina, do que uma pessoa que executa em si. Até porquê quando pensamos em escalabilidade, precisamos de testes em diferentes níveis e muitas vezes iremos usar diferentes tecnologias para isso. Sendo assim, precisaremos de profissionais com experiências em linguagens e frameworks diferentes. E é nesse ponto que vejo que atuaremos mais como guias, ensinando como aplicar as técnicas em diferentes frameworks.

Como bibliografia, as certificações da ISTQB passam por várias destas técnicas (no Brasil, o órgão representante é o BSTQB). Outra recomendação é o Livro Agile Testing da  que agrega a parte da agilidade aos fundamentos de teste.

2. Quando começou a trabalhar com Playwright e qual foi o processo de decisão por este framework?

Helen:
Uso o Playwright desde fevereiro de 2023, mais ou menos. Não temos automação na empresa e eu estava procurando um framework para fazer meu TCC da faculdade. Meu mentor de estágio sugeriu e não larguei mais. Hoje meu projeto ainda está em desenvolvimento e sei que a equipe dos Estados Unidos está usando também em paralelo.

Renata:
É muito bom e importante termos mentores que nos auxiliem durante nossa jornada. Atualmente existem tantas ferramentas, tantas técnicas, tantas soluções que é difícil mesmo saber de tudo e direcionamento facilita demais. Uma dica complementar que eu costumo dar é que não devemos nos apegar a uma ferramenta. O Playwright tem sim muitos recursos que outros frameworks não tem; mas existem limitações e com toda certeza ele não é o melhor framework para todos os sistemas. Eu sempre recomendo fazer uma POC (prova de conceito) para avaliar uma ou duas ferramentas extras e decidir qual é a melhor para o time. Além disso, é importante entender qual o problema que você quer resolver ao automatizar os testes e qual a infraestrutura disponível. Pois só “implementar” testes não resolve o problema. Precisamos também ter uma rotina de execução regular para que os testes identifiquem os erros e claro, uma forma de comunicação adequada para que o time seja informado (o quanto antes) no caso de falhas.

Como bibliografia, recomendo esse artigo que escrevi: Como escolher um framework de automação, e o curso grátis da Angie Jones – Setting a foundation for successful test automation. Com esses materiais, qualquer decisão que usar para a escolha do framework será muito bem embasada e evitará problemas futuros.

3. Em relação a pipeline, como é sua estrutura?

Helen:
Ainda não está em produção e eu ainda não tenho conhecimento de pipeline. Mas o plano é rodar a cada deploy e release.

Renata:
É muito importante adicionar os testes à pipeline desde o início. É melhor ter 5 testes rodando estáveis do que 10 implementados sem ninguém utilizar. Eu recomendo, desde o primeiro testes, já configurar a execução da pipeline. Isso dá visibilidade para o projeto e agrega valor para o time. As vezes dedicamos muito tempo implementando novos testes mas ninguém nunca vê. Isso proporciona uma “má imagem” da nossa área também. O restante do time irá “aprender” que isso é o padrão e muitas vezes isso não contribui para a valorização da nossa área de qualidade. A Angie fala sobre isso no curso dela. E também existem referências em várias outras fontes que eu citei aqui. Voltando mais uma vez em “qualidade ser responsabilidade de todos”, neste caso você pode acionar o setor de DevOps da empresa para te ajudar a fazer isto. É importante ressaltar que precisamos entender bem o que estamos solicitando a este setor e criar uma convivência saudável pois interação entre qualidade e DevOps é uma das mais fortes em um time de alta performance. Atualmente isto é tão comum que criou-se um novo papel “TestOps” que se dedica a todo o ciclo do software até a sua entrega. Neste papel, o foco está em criar experiências de teste que sejam mais rápidas para o seu time, como por exemplo frameworks de unit, api, ui testing para que todos os membros do time possam rapidamente adicionar testes, e principalmente o gerenciamento e otimização de pipelines para proporcionar maior estabilidade nas releases. Não podemos deixar de fora “Observabiliity” que é o monitoramento e alerta em caso de falhas e definição de estratégias de recuperação no caso delas acontecerem.

Como bibliografia aqui, vou listar alguns treinamentos gratuitos:

Para Playwright especificamente, eu falo sobre integração contínua e observability com Github Actions e Slack no curso de Playwright Avançado: https://testautomationu.applitools.com/playwright-advanced/chapter6.html 

4. Você já percebeu algum valor adicionado ao projeto desde que começou a usar Playwright?

Helen:
Como disse anteriormente, ainda não está em produção mas, só de precisar rodar muito mais vezes os testes para poder escrever a automação, já descobri outros bugs.

Renata:
Além dos itens que comentei na questão anterior, um outro fator importante de se considerar ao avaliar o “valor adicionado ao projeto” é a manutenibilidade do código, a estabilidade e a performance dos testes. É importante, desde o princípio, definir uma arquitetura que faça sentido, utilizar design patterns (page object model, etc), adotar um bom método de code review, fazer uso de ferramentas de análise de código estático (ESLINT, SonarQube, etc).

Como bibliografia, tenho um artigo sobre Page Object Model e pretendo adicionar alguns outros, e também um curso de Arquitetura de Testes. Um dos Playwright Ambassadors que mais compartilha conteúdos neste aspecto é o Butch Mayhew.

5. Você tem experiência com outros frameworks? Em que o Playwright se destaca quando de forma geral?

Helen:
Usei apenas o Specflow juntamente do Playwright enquanto escrevia o TCC, mas retirei após um tempo. Não me parecia viável para a nossa empresa.

Renata:
Nunca utilizei Specflow, mas gostei que já tenha retirado rsrs. O Playwright por si só já é bem robusto então acredito não ser necessário utilizar outros frameworks em conjunto. Pelo menos para testes de UI e de API. 🙂

6. Tem alguma coisa que você acha que ainda não está legal no Playwright?

Helen:
Gostaria que existisse mais materiais usando C#, .Net com MSTest e Visual Studio 2022. Facilita pros iniciantes como eu. 🙂

Renata:
Sim, entendo. A equipe do Playwright prioriza nodeJS já que a maioria dos usuários vem desse ambiente. Acredito que nesse aspecto, uma alternativa seja se conectar mais a comunidade. O Discord do Playwright é muito ativo e o time do Playwright participa ativamente dele. Recomendo utilizar frequentemente para aumentar o conhecimento.

É importante lembrar também que, ao escolher o framework de teste, é importante avaliar qual a linguagem que ele oferece maior suporte. Tenho um artigo falando sobre a escolha da linguagem para Playwright.

7. Qual é sua funcionalidade favorita do Playwright?

Helen:
Como sou muito iniciante, o Codegen facilita muita coisa.

Renata:
Voltando no aspecto da qualidade de código e manutenibilidade. Pessoalmente eu não recomendo Codegen para iniciantes. Qualquer ferramenta de geração automática, não tem como considerar o contexto do projeto e esses fatores. E isso gera a erros comuns que terão impactos grandes em um futuro não muito distante (geralmente 6 meses a 1 ano já começa a observar problemas de instabilidade e performance, sem contar na dificuldade de manutenção de código comumente criando uma bola de neve onde passa se a adicionar novos testes pra todos os cenários, já que atualizar cenários existentes fica quase impossível). O Codegen é desnecessário se você entende bem como utilizar locators e como lidar com os comandos do framework.
As minhas funcionalidades preferidas do Playwright são: retry automático, paralelismo automático, autowait nos comandos, report incluso e o Trace Viewer!

Como bibliografia, recomendo:

8. Qual é a IDE que você utiliza para desenvolver os testes? E você utiliza mais linha de comando ou o plugin do Playwright na IDE?

Helen:
Uso o Visual Studio 2022 apenas.

Renata:
Legal! As IDEs atualmente são também muito robustas e permitem que façamos quase tudo através delas. Outras IDEs que são comumente utilizadas para Playwright são o VSCode e o Aqua. Um bom entendimento de como rodar os testes via linha de comando também considero importante pois caso você mude de linguagem ou framework, é legal entender o que está acontecendo por trás dos botões rsrs. Neste caso, é ler a documentação do framework mesmo.

9. O que acha do Codegen do Playwright?

Helen:
Um bom facilitador, mas as vezes não tão claro.

Renata:
Nada a adicionar aqui, já comentei meu ponto de vista na pergunta 7 🙂

10. Já utilizou GitHub Copilot pra implementar os testes? E utilizou Inteligência Artificial para criar algum teste ou alguma função (page object model por exemplo) no seu projeto? Tem alguma opinião sobre esses pontos?

Helen:
Ainda não tenho nada em git, mas passei a usar o POM depois das suas dicas e da engenheira de automação da divisão dos USA. Não tenho uma opinião formada porque tenho muito ainda o que aprender.

Renata:
Git, Github, Github Copilot são coisas diferentes (e POM não tem a ver diretamente com esses temas, mas pode ser gerado com Inteligência Artificial).

Git é um sistema de controle de versões distribuído. Ou seja, quando você está trabalhando em um time, é comum você ter um lugar onde você “commita” o código que está trabalhando (chamado repositório), cria branches, baixa atualizações de código submetidas por outras pessoas, etc. 

GitHub é uma plataforma na nuvem que permite e facilita o uso do sistema de controle de versões. Além do GitHub tem por exemplo o GitLab, o BitBucket, etc. Esas plataformas rodam em cima do Git. Uma vez tendo o repositório Git, você disponibiliza o código para uso através das plataformas. Em resumo o GitHub permite que você e outras pessoas interajam com projetos em Git. Sem o GitHub, você veria tudo somente através de linha de comando e localmente.

GitHub Copilot é um produto de Inteligência Artificial do GitHub que te auxilia na escrita de código. Ao digitar, o GitHub Copilot irá sugerir um bloco de código utilizando GenAI. Além disso, ele oferece um Chat pra você perguntar dúvidas relacionadas ao código e irá também apresentar alguns erros e explicações de como solucionar os problemas.

Além do GitHub Copilot, muitos profissionais de qualidade tem utilizado Prompt Engineering para migrar de uma linguagem para outra (por exemplo, neste artigo eu usei um ChatGPT para converter um código em Playwright para Cypress já que eu não tenho conhecimento em Cypress). Outro uso é para descrever cenários de teste baseado em uma documentação ou uma URL. Outro exemplo é para criar POMs passando uma URL.

A minha opinião aqui é semelhante à do Codegen. Eu não recomendo o uso de Inteligência Artificial para iniciantes. Para que a Inteligência Artificial seja bem utilizada, é necessário saber técnicas de prompt para um resultado mais preciso. Ainda sim, é importante saber o que você está buscando para avaliar a resposta, já que ela é uma inteligência ARTIFICIAL. Ao mesmo tempo, é legal ir familiarizando com as ferramentas disponíveis no mercado, e principalmente os fundamentos de Inteligência Artificial já que a tendência é que ela acelere muito o desenvolvimento de tarefas na área de software (e em outras também né?!).

Bibliografia: 

11. Qual seria sua dica de ouro pra pessoas que estão pensando em usar Playwright?

Helen:
Aprenda e use, ainda tenho muita esperança de que escolhi o melhor framework pro meu projeto. É rápido e não me parece ser tão complicado depois que se pega o jeito.

Renata:
Não só para o Playwright mas para qualquer outro framework, lembre-se que o framework em si não resolve nenhum problema. Em conjunto com o framework, existem todas as técnicas de teste e padrões de qualidade de desenvolvimento que devem ser seguidos para um resultado bem sucedido. Aprendizado demanda tempo. Não se cobre muito, comece aos poucos. E entenda que levará cerca de 5 anos ou até mais até você começar a assimilar as coisas com facilidade. É assim em tudo na vida: Aprender a andar, a falar, dirigir, cozinhar, falar outro idioma, fazer uma maquiagem, e tudo mais. Aproveite o caminho, tenha pessoas boas ao seu redor, e seja humilde principalmente para dizer que não entendeu. Todos nós recebemos ajuda um dia, é normal! Inclusive existe um programa de mentoria gratuita com profissionais de várias áreas e de vários lugares do mundo: https://adplist.org/

Referências Complementares:

Published by raptatinha

Leave a Reply

Your email address will not be published. Required fields are marked *