Quando se trata de implementar testes em uma Pipeline de entrega contínua, é natural que também surja a necessidade de estabelecer Quality Gates. Mas será que simplesmente adicionar testes à pipeline já é o suficiente para garantir uma sólida estratégia de qualidade? Ou será que precisamos considerar outros aspectos além da mera execução dos testes durante o processo de deploy? Neste post, vamos explorar esse tema e discutir a importância dos Quality Gates em um contexto mais amplo.

O que são Quality Gates?

Costumo brincar com uma analogia bem nerd, mas acho que vocês vão entender (ou não…😝).  Se você conhece Cavaleiros do Zodíaco, você vai entender. Imagina comigo:

• A aplicação testada são os Cavaleiros de Bronze
• O caminho até o Santuário de Atena é a pipeline
• As 12 Casas dos Cavaleiros de Ouro são os Quality Gates
• E o ambiente de Produção é o Santuário de Atena

O objetivo dos cavaleiros de bronze é o mesmo de uma aplicação dentro de uma pipeline (caminho até Atena). Ultrapassar todos os Quality Gates (as 12 Casas) tendo sua qualidade (força) atestada para conseguirem chegar no seu objetivo, o ambiente de produção (Santuário de Atena). 

Eu amo essa analogia, rsrsrs… 😁

Mas de forma didática, Quality Gates são pontos de verificação estratégicos que permitem avaliar se uma determinada aplicação atende os critérios de qualidade definidos. Esses critérios são usados para determinar se uma entrega está pronta para avançar para a próxima etapa da pipeline até chegar à produção ou voltar para revisões devido a problemas encontrados.

A simples inclusão de uma etapa de testes em uma pipeline não garante automaticamente a existência de um Quality Gate efetivo. É essencial estabelecer estratégias adequadas para garantir que, caso sejam encontrados bugs críticos que impactem os fluxos de negócio essenciais, o Quality Gate reconheça que os critérios de qualidade não foram cumpridos e impeça a progressão do software na pipeline.

A Pipeline

Não vou falar de regra específica para determinar quais testes devem estar incluídos na pipeline de uma aplicação. Isso dependerá da maturidade da equipe, do tipo de aplicação sendo testada, da estrutura da pirâmide de testes e, principalmente, da cultura de qualidade que está sendo promovida dentro da equipe ou do domínio. Então, entendemos que existem etapas anteriores à construção de uma pipeline de qualidade que precisam estar bem estabelecidas para que funcione corretamente.

No entanto, para ilustrar, vamos imaginar uma pipeline de entrega para uma aplicação backend. Ela pode seguir a seguinte estrutura:

Cada estágio de teste ilustrado acima se configura como um Quality Gate para a pipeline. Cada estágio fornecem suas saídas (geralmente exit code 0 ou 1) e se preciso dados complementares para informar para a pipeline se os critérios dos Quality Gates foram cumpridos ou não. E caso não tenham sido cumpridos, é fundamental que a pipeline seja capaz de realizar um rollback da modificação realizada, revertendo o software para um estado estável e funcional anterior, garantindo assim a integridade dos ambientes, seja ele produtivo ou não produtivo.

Teste Fumaça ou Teste de Regressão?

Uma dúvida que costumo ver bastante é: “Adiciono os meus Testes de Regressão ou os Testes de Fumaça na pipeline?”

Antes de falar a minha visão sobre, vamos relembrar/conhecer de forma bem resumida o conceito de cada um desses tipos de testes.

• Teste de Regressão: Utilizado para verificar se uma modificação recente em um aplicação impactou negativamente funcionalidades ou comportamentos que já estavam funcionando corretamente anteriormente. O objetivo é garantir que as alterações recentes não tenham introduzido novos bugs em funcionalidades existentes.
• Teste Fumaça/Smoke Test: Utilizado para verificar rapidamente se as principais funcionalidades de um sistema estão funcionando corretamente. Ele envolve a execução de um conjunto básico de cenários de teste que abrangem as principais funcionalidades ou fluxos de negócio da aplicação. O objetivo é identificar problemas graves que possam afetar o uso básico do sistema.

Com os conceitos entendidos, vamos lá. 

A decisão de incluir um teste de regressão ou um teste de fumaça em uma pipeline depende muito do contexto e principalmente dos requisitos de qualidade do projeto. Por exemplo:

Uma aplicação possui uma suíte de 10 cenários de testes, sendo que 5 são testes com alta criticidade, 3 com média criticidade e 2 com baixa criticidade. E durante a execução dos testes de regressão na pipeline, 1 cenário de criticidade baixa falhou. 

Nesse caso, faz sentido bloquear a promoção do código para produção? Para mim não. Vamos entender o porquê dessa minha visão…

Em uma pipeline, minha abordagem preferencial é priorizar a execução dos testes de fumaça como um Quality Gate. Como vimos anteriormente, esses testes abrangem um conjunto menor e mais crítico de cenários, permitindo uma verificação rápida dos fluxos essenciais do negócio. Com um tempo de execução menor, eles aceleram o progresso das promoções no pipeline.

Os testes de regressão também são executados na pipeline, em paralelo com o processo de promoção no próximo ambiente. No entanto, eles têm como foco os cenários com menor criticidade e um conjunto maior de cenários, o que consequentemente eleva o tempo de execução, portanto, não atuam como um Quality Gate. Caso ocorra uma falha durante esses testes, ela não impedirá o progresso da promoção, mas realizará notificações para que a equipe possa tomar as medidas necessárias.

Essa abordagem permite que os testes de fumaça atuem como um checkpoint inicial para garantir a estabilidade básica e a funcionalidade essencial do sistema antes de prosseguir com os testes de regressão mais abrangentes. Dessa forma, podemos identificar problemas graves rapidamente e manter um fluxo de implantação mais ágil e confiável.

Nesse sentido, poderíamos ter algo como:

E os demais tipos de teste?

A inclusão de mais tipos de testes na pipeline, dependerá bastante da maturidade da pirâmide de testes que sua você e sua equipe implementaram e seguem. Mas usando o exemplo que estou seguindo nesse post, podemos ter os seguintes critérios de Quality Gate:

• Testes Unitários: Certificar que todos os testes unitários foram executados com sucesso e que a cobertura de testes está em um nível aceitável (por exemplo, acima de 80%).
• Teste de Mutação: Garantir que os testes de mutação tenham sido executados e que todas as mutações detectadas tenham sido adequadamente cobertas por testes. 
  • Esse tipo de teste tende a ter um tempo de execução grande dependendo da quantidade de mutantes gerados, é valido avaliar uma forma de que sejam gerados mutantes apenas para as unidades que foram alteradas.
• Testes Estáticos: Ferramentas de Testes Estáticos (como o SonarQube, por exemplo) geralmente possuem configurações bem sólidas de Quality Gates. Então basta integrar a ferramenta para permitir que as regras sejam validadas e as saídas sejam lidas pela Pipeline.
• Teste de Integração: Assegurar que os testes de integração tenham sido executados com sucesso, validando a comunicação e a integração correta entre os componentes do sistema.
• Teste de Contrato: Garantir que a comunicação entre as aplicações que se integram com a aplicação testada esteja em conformidade com os contratos estabelecidos.

Futuramente vou escrever um post para falar exclusivamente da pirâmide de testes, para ajudar nessas tomada de decisão.

E é isso pessoal…

Esse post não foi sobre algo exclusivo do Robot Framework, é algo mais abrangente que ultrapassa qual framework está sendo utilizado para realizar os testes na camada de aceitação, porém achei que era um assunto interessante para trazer para vocês aqui.

Espero que esse post possa ajudar vocês com suas dúvidas em relação à Quality Gate e Pipelines com esteiras de qualidade.

Grande abraço a todos

Valeu!

\o/