Os testes automatizados na Hotmart
Cultura, Separação entre os times, principais tecnologias e desafios.
Conheça o dia a dia da Hotmart em relação aos seus testes automatizados.
Você já deve ter se deparado com vários posts ou blogs falando sobre testes automatizados, sobre as inúmeras ferramentas de testes automatizados, sobre a famosa pirâmide de testes, sobre um tutorial básico de como implementar testes em diferentes camadas da pirâmide, entre vários outros materiais que recheiam nossas leituras dia a dia. Mas alguém já te contou sobre a verdade de tudo isso? De como isso é implementado em uma empresa de grande porte como a Hotmart? Então se você quer entender um pouco mais sobre isso, continue a leitura porque ao longo deste tutorial , vamos te contar um pouquinho sobre o processo de aumentar a qualidade de projetos através dos testes automatizados.
Como a Hotmart funcionava a 6 anos atrás?
Naquela época eram praticamente 4 grandes times, cada um com suas squads que cuidavam de um ponto específico dos produtos. Nessa época não havia nenhuma pessoa dedicada aos testes automatizados, todos os(as) desenvolvedores(as) eram responsáveis por criar a stack de teste com o necessário para garantir a qualidade do produto. Nessa época era mais fácil conseguir êxito nessas tarefas porque a equipe era menor, havia mais desenvolvedores(as) experientes e conseguimos andar juntos nas estratégias de qualidade.
Porém, com o crescimento muito acelerado da empresa, as equipes elevaram em número de pessoas, o produto ficou mais complexo e a quantidade de usuários aumentou absurdamente. Como consequência, surgiu cada vez mais a necessidade de criar um processo mais robusto de qualidade para continuar mantendo a experiência do nosso usuário a melhor possível.
Recorrendo a ajuda especializada
Tivemos outras tentativas isoladas ao longo desse tempo, mas uma das mais determinante foi a quase 3 anos atrás, apoiada por uma empresa especializada em como aumentar de forma saudável e escalável a qualidade dos produtos principalmente os legados e de maior impacto organizacional. No primeiro mês focamos em entender a estrutura atual, quais seriam as tecnologias que usaríamos nesse processo e principalmente qual era o nosso objetivo.
Concluímos que para garantir os fluxos mais críticos da nossa aplicação conforme nossa estrutura naquele momento, o mais adequado para garantir isso em um tempo hábil seria os testes de ponta a ponta, ou seja, o nosso famoso e polemico “E2E”.
Decidindo a tecnologia
Com o objetivo e estratégia bem definidos, iniciamos a etapa de definição da tecnologia. Aqui na Hotmart existe sempre muita liberdade e flexibilidade para as pessoas definirem qual tecnologia melhor se adapta a sua necessidade, tendo em vista isso criamos uma planilha simples com algumas tecnologias e pontos importantes para a escolha realizada pelos próprios(as) desenvolvedores(as).
A planilha era composta por critérios de decisão, que eram eles: Cross Browser, Documentação e recursos, Velocidade de Execução, Paralelismo / Dashboards / Infra, Comunidade ativa, suporte a mobile, fidelidade da simulação do usuário, debugging, produtividade / Manutenção / Curva de aprendizagem, sincronismo / Flakiness e Relatórios. Cada um desses critérios de decisão tinha um peso específico de relevância conforme a realidade da época para a nota final. A avaliação era simples, consistia em uma nova de 0 a 10, onde 0 era não atende e 10 era atende 100% o critério específico.
Colocamos 3 diferentes frameworks para participar dessa votação, que eram eles, Cypress, TestCafe e Protractor com Serenity-js. Após várias discussões, vários pontos de vista, várias visões sobre os frameworks em questão, tivemos enfim uma decisão final bem apertada entre eles, principalmente entre Cypress e Protractor com Serenity-js, que foi de 375 pontos para o Cypress, 373 pontos para o Protractor com Serenity-js e 357 pontos para o TestCafe. Portanto, ao final da avaliação , a escolha feito foi o Cypress para o campo de batalha (e isso não é só uma expressão).
Implementando os primeiros cenários
Como toda maravilhosa lua de mel, nós iniciamos o processo de implementação desses testes, reunimos todas as gerencias impactadas, elaboramos quais seriam os fluxos mais críticos que nunca deveriam apresentar erro e começamos a implementar com a nossa consultoria esses cenários de testes.
Um mundo novo, parecia que essa seria a resolução de todos os problemas e que seria muito fácil manter e evoluir esses testes. A execução local dos testes era maravilhosa, não dava erro, conseguíamos garantir tudo funcionando e em um tempo razoável que ainda sabíamos que ia melhorar quando fosse para a pipeline.
Para apoiar toda nossa estrutura começamos a criar componentes para o Cypress que facilitariam o dia a dia do desenvolvedor e criamos ainda uma robusta criação de massa de dados para atender qualquer cenário que por ventura precisaria ser implementado.
Desafios
O primeiro problema surgiu quando não estávamos totalmente alinhados com as equipes de negócio e acabamos desenvolvendo os testes automatizados sem estar alinhados com as mudanças no produto, ou seja, a cada teste feito precisávamos refazer algumas pontas por que o sistema evoluiu e não estava mais conforme o escopo inicial.
Outro grande problema foi em relação à cultura dos times de desenvolvimento perante aos testes automatizados e principalmente aos testes de ponta a ponta “E2E”. Em um primeiro momento a maioria dos times enxergou os testes como mais um passo no desenvolvimento do produto e mais uma fase que iria faze-los atrasar as entregas. Além de várias desenvolvedores que trouxeram experiências negativas que tiveram anteriormente com esse tipo de testes e tentaram colocar tudo isso como coisas ruins. Não era raro escutar coisas como, “Testes de ponta a ponta demora demais”, “Várias empresas estão tirando os testes de ponta a ponta de sua stack”, “Estamos indo contra os padrões de projeto”, e etc.
Outro ponto difícil foi a falta de domínio do time com os testes de ponta a ponta e os vários problemas de “Race Condition”, “Flakiness” e claro o nosso ambiente de testes que é atualmente compartilhado por todos os desenvolvedores e muitas vezes ficava meio instável por conta de testes realizados incorretamente. Isso foi e é um grande problema até hoje porque quando não sabemos o problema dos testes colocamos a culpa no nosso ambiente de desenvolvimento e acabamos não avaliando a fundo a causa raiz e consequentemente corrigindo o erro para sempre.
E por último, o problema que acho que todos cometemos quando estamos lidando com os testes de ponta a ponta, o qual é acreditar que eles são uma resolução universal para tudo, a famosa “bala de prata” e acabar colocando vários testes que não deveriam estar nessa camada. Naturalmente essa já uma linha bem difícil de estabelecer, mas em muitos casos extrapolamos e acabamos excedendo isso em muitos testes.
Conquistas
A primeira grande conquista foi em relação ao tempo de execução. Fizemos um trabalho muito grande com testes de paralelização de execução dos testes, também fizemos um grande trabalho de criar componentes com as melhores práticas do mercado e práticas recomendadas pelo próprio criado do framework. Por exemplo, cy.wait no nosso código foi proibido. Chegamos a uma média do nosso pior cenário que era a execução de aproximadamente 50 testes de fluxos grandes em 4 minutos. Com isso conseguimos quebrar o paradigma que todos os testes de ponta a ponta são extremamente lentos.
Outra grande conquista que tivemos foi a de colocar o assunto qualidade na pauta de conversas. O assunto qualidade e testes automatizados estavam sendo discutidos em todas as reuniões diárias, semanais, mensais, retrospectiva e qualquer ritmo de desenvolvimento que tínhamos. O debate sobre qualidade do software estava aflorado e todos tinham um palpite e queriam realizar algo, e no final sempre faziam algo para garantir esse fluxo.
Conseguimos também alcançar o principal objetivo, que era não deixar um problema grave ir para a produção e consequentemente afetar a experiência do nosso usuário final. Isso foi um grande fator de impulsão para nos apoiar e conseguirmos mostrar valor para os gestores e os desenvolvedores e nessa altura o testes não era mais apenas uma coisa a mais que estava no fluxo de desenvolvimento.
E quem disse que os testes pegam somente erros em produção? Com a execução diária dos nossos testes conseguimos começar a entender problemas e dificuldades que os(as) desenvolvedores(as) tinham na fase de desenvolvimento e consequentemente diminuíam a produtividade e qualidade. Por exemplo, conseguimos perceber nesse dia a dia que o nosso ambiente de desenvolvimento é muito complexo e quase impossível de entender todos os conceitos, isso fazia com que o(a) desenvolvedor(a) usasse muito o ambiente compartilhado, acarretando instabilidade do mesmo. Isso foi muito importante para perceber um gargalo totalmente escondido.
Como Estamos hoje
Atualmente ainda estamos enfrentando vários desafios no dia a dia, mas com mais conquistas do que revés. Estamos agora na fase de criar outras camadas de testes, como testes de componentes, contrato, integração e unitários.
Também estamos trabalhando arduamente diariamente para mostrar o valor dos testes para todos os envolvidos e como ele é sem dúvidas um grande aliado na busca pela ideal qualidade de software e não apenas mais uma coisa na etapa de desenvolvimento.
Outra coisa importante é que estamos também tentando melhorar o dia a dia do nossos desenvolvedor(as) e o deixando cada vez mais feliz, tendo em suas mãos a facilidade de ter um ambiente seguro e estável para que possam desenvolver
Conclusão
Implementar o processo de qualidade de desenvolvimento de software em empresas de grande porte não é fácil, existem vários desafios, desde a implementação de fato até a cultura das pessoas envolvidas no desenvolvimento de software. Mas depois os desafios são superados os ganhos com esses processos são inegáveis e irreversíveis. Espero que tenhamos conseguido passar uma visão real de como foi a nossa experiência e que possa ajudar a pular etapas e não cometer alguns erros que cometemos no início.
Saiba Mais
Quer saber como a Hotmart realiza todo esse processo? Você pode conferir e participar do Hot N’ Code Meetup, organizado pela Hotmart, onde trazemos a galera que trabalha aqui para contar experiências para a comunidade. O conteúdo desse post é baseado na minha palestra do Hot N’ Code de setembro de 2022, e você pode conferir o Meetup completo aqui.
