Pare de executar testes com sua ferramenta CI/CD

A implementação de uma infraestrutura de testes e fluxo de trabalho consistentes para aplicativos nativos da nuvem tem seus desafios. Múltiplas partes interessadas têm necessidades diferentes em relação a testes/QA, a pilha de ferramentas de teste está em constante evolução de acordo com novas tecnologias e requisitos, os pipelines de CI/CD/GitOps estão transformando a maneira como entregamos software e os testes de software legado e de corte. os componentes de ponta precisam ser mantidos para garantir a entrega de aplicativos de alta qualidade aos usuários finais.

Com o advento das ferramentas e fluxos de trabalho de CI/CD, pareceu natural usar CI/CD também para executar testes. Afinal, os testes fazem parte do ciclo de vida de entrega de software, e automatizar as execuções de testes como parte de compilações e implantações faz sentido em um nível conceitual. Infelizmente, muitas ferramentas de CI/CD colocam muito pouca ênfase nas necessidades específicas de testes e controle de qualidade. Para eles, o teste é apenas mais uma tarefa a ser executada no pipeline, o que muitas vezes faz com que o suporte adicional a testes em ferramentas de CI/CD pareça mais uma reflexão tardia do que um objetivo principal.

Adicione o cenário comum em que várias ferramentas de CI/CD são usadas na mesma organização: Jenkins para construir seu backend de microsserviços Java, ações GitHub para construir (e implantar?) seus aplicativos frontend e talvez até algo como Argo para adotar uma abordagem GitOps para implantando seus aplicativos no Kubernetes. Os testes muitas vezes não são apenas uma reflexão tardia, mas essa reflexão agora está espalhada por várias ferramentas! O que poderia dar errado?

Vamos nos aprofundar em seis necessidades específicas de uma estratégia de automação de testes bem-sucedida e como confiar em ferramentas de CI/CD muitas vezes o enviará para o pântano de testes sem retorno (TSONR — é aqui que você leu primeiro!).

1. Suporte consistente a ferramentas de teste

Não importa como você configura as execuções de teste em seus pipelines e ferramentas de CI/CD, manter suporte consistente para ferramentas legadas, ferramentas modernas, alterações de versão e testes legados é um desafio.

Uma das últimas coisas que você deseja ouvir no final do dia é “nossa ferramenta de CI/CD não oferece suporte à sua estrutura de teste” ou “não podemos executar várias versões de (ferramenta de teste) em nossos pipelines”. Você terá que atualizar todos os seus scripts para funcionar com a versão X.”

Muitas ferramentas de CI/CD dependem de plug-ins para oferecer suporte a uma ferramenta/versão de teste específica – o que não é uma garantia de consistência. Seu substituto geralmente é algum tipo de ambiente de script, que pode fazer o trabalho, mas adiciona complexidade e sobrecarga de manutenção, dificultando o dimensionamento e a diversificação dos esforços de teste.

2. Ambiente consistente de execução de testes

“Funciona na minha máquina.” Você certamente já ouviu e pronunciou essas palavras com descrença quando um teste que você elaborou meticulosamente em um ambiente não fornece os resultados desejados quando executado em um ambiente diferente (mais importante).

A execução do mesmo conjunto de testes deve fornecer resultados consistentes, obviamente. Infelizmente, executar testes em um ambiente de ferramentas multi-CI/CD geralmente resulta em resultados que variam dependendo de onde (e como) você os executa. Diferentes ferramentas de CI/CD têm tempos de execução, ambientes e infraestrutura diferentes, tornando difícil prever a consistência de seus esforços de teste, especialmente quando se trata de testes não funcionais, como testes de desempenho, segurança e conformidade. Acrescente a isso que os testes executados localmente durante o desenvolvimento geralmente são executados “manualmente” diretamente com a ferramenta de teste correspondente, que geralmente está longe de um ambiente de teste ou produção.

3. Execute testes sempre que necessário

Executar testes automatizados como parte do pipeline de CI/CD é uma prática comum, mas executar esses testes fora do pipeline é difícil, e você não deseja executar novamente uma compilação inteira apenas para executar novamente alguns testes atualizados em um ambiente de desenvolvimento.

A possibilidade de executar testes fora de seus pipelines de CI/CD, tanto manualmente (por exemplo, testes de carga) ou em resposta a outros eventos do sistema (como um evento Kubernetes) é essencial em uma infraestrutura distribuída e diversificada para garantir que ambos DevOps e as equipes de controle de qualidade podem (re)executar testes sempre que necessário.

4. Execute testes em escala

A execução de testes automatizados em escala envolve dois vetores:

1. Escalonamento de testes de carga para gerar carga massiva para simular cenários de pico de uso para seus aplicativos ou APIs.
2. Dimensionamento de testes funcionais/end-to-end (E2E) para cobrir uma matriz de cenários de execução, incluindo diferentes navegadores, sistemas operacionais, usuários, etc.

As ferramentas de CI/CD raramente terão funcionalidade dedicada que atenda a qualquer uma dessas necessidades no contexto da execução de testes. Eles podem permitir que você inicie diferentes “trabalhadores”, mas toda a lógica além daquela em relação à sua ferramenta de teste em questão terá que ser gerenciada por scripts personalizados e/ou soluções de terceiros.

5. Painel único para resultados de testes

Obter acesso a resultados de testes e artefatos consistentes em todas as ferramentas de teste usadas em seus pipelines de CI/CD é fundamental para a solução de problemas táticos de testes com falha e para a compreensão estratégica dos esforços gerais de teste.

Infelizmente, a maioria das ferramentas de CI/CD tem pouco conhecimento inerente sobre os resultados dos testes em um nível superior. Eles podem facilitar a visualização da saída de log/artefato de cada teste individual, mas agregar métricas de qualidade, como taxas de aprovação/reprovação e números de execução em todas as suas ferramentas de teste, não é preocupação deles e fornecer a você uma maneira fácil de acessar dados específicos. resultados de execução de teste e artefatos para solução de problemas aprofundados de testes com falha geralmente exigirão que você mesmo faça uma boa quantidade de scripts ou exporte-os para ferramentas externas para uma análise mais profunda.

6. Dando controle ao controle de qualidade

Precisa atualizar alguns argumentos ou a versão da sua ferramenta de teste em execução nos pipelines? Registre um ticket com a equipe DevOps e espere que eles tenham tempo ainda hoje, ou esta semana ou mês.

Depois que a automação de testes é entregue às equipes que gerenciam pipelines de CI/CD, o controle de qualidade geralmente tem pouco controle ou percepção sobre essa automação, o que pode retardar consideravelmente a evolução dos testes em seus pipelines de CI/CD.

As ferramentas de CI/CD raramente têm a granularidade de controle de acesso baseada em função necessária para dar aos testadores acesso apenas aos aspectos de teste dos pipelines de construção, portanto, melhorias/mudanças iniciadas pelo controle de qualidade relacionadas à execução de testes geralmente precisam passar por um processo tedioso antes de serem implementadas , causando desde frustração nas equipes até falta de cobertura de testes.

Alternativamente, o QA tem acesso a áreas da infraestrutura do edifício que não deveria ter, o que poderia introduzir preocupações de segurança numa organização mais regulamentada.

OK, e agora?

OK, você ouviu os argumentos e esperançosamente pensará duas vezes antes de pedir à sua equipe DevOps para automatizar seus scripts Playwright ou coleções Postman em seus pipelines daqui para frente.

Mas como você enfrenta todos esses desafios e dissocia a execução de testes de seus pipelines de CI/CD sem sacrificar o valor dos testes no próprio CI/CD?

Solução 1: uma plataforma de orquestração de testes

Testkube é uma plataforma de orquestração de testes para CI/CD construída especificamente para resolver os problemas acima (e mais):

1. Ele suporta a execução de testes para qualquer ferramenta/versão de teste sem a necessidade de scripts extensos.
2. Ele usa Kubernetes para executar todos os seus testes, o que traz um ambiente de execução consistente e escalável para todos os seus testes.
3. Ele permite que você execute seus testes sempre que necessário — como parte de CI/CD, manualmente a partir de uma CLI, painel ou API, por meio de gatilhos externos, etc.
4. Ele tem suporte integrado para dimensionar qualquer ferramenta de teste – seja horizontalmente para geração de carga ou verticalmente para testes funcionais/E2E de vários cenários.
5. Ele fornece um painel único para todos os resultados e artefatos de teste, garantindo que você tenha uma maneira consistente de solucionar problemas de qualquer teste e coletar insights operacionais e de qualidade para suas atividades de teste ao longo do tempo.
6. Ele separa a orquestração/autoria/configuração de automação de testes de suas ferramentas de CI/CD, colocando o controle de qualidade de volta no controle de todas as atividades de execução de testes em seu ambiente.

Testkube sempre executa testes em sua própria infraestrutura, ajudando você a gerenciar custos e aspectos de segurança das execuções de testes. O Testkube Dashboard pode ser hospedado na nuvem ou executado no local (air-gap, se necessário), oferecendo alternativas fáceis de iniciar e compatíveis com segurança, desde uma avaliação até a configuração de produção.

Opção 2: script manual e fita adesiva

Se o Testkube não for para você, quais são suas opções para contornar alguns dos desafios acima?

Se você estiver usando pelo menos uma ferramenta de CI/CD em sua organização, poderá criar micropipelines específicos para testes e chamar/reutilizar aqueles de seus pipelines de construção existentes. Isso poderia ajudá-lo com os pontos 3, 5 e 6 acima.

• Esses pipelines podem ser executados sempre que necessário (embora os testes individuais dentro deles não possam).
• Todos os resultados dos testes serão encontrados na saída desses pipelines, embora se você usar várias ferramentas de teste, elas ainda serão desconectadas.
• Você pode garantir que os testadores/controle de qualidade tenham acesso para gerenciá-los sem precisar alterar o restante das configurações de compilação.

Infelizmente, o nível de suporte para os outros pontos irá variar muito dependendo da ferramenta CI/CD que você está usando e quanto esforço/tempo você deseja investir na criação/manutenção de scripts personalizados.

Resumo

A execução automatizada de testes é uma prática obrigatória em pipelines de CI/CD em grande escala, mas traz muitos desafios não abordados pelas ferramentas de CI/CD. As deficiências das ferramentas de CI/CD neste aspecto dificultam uma estratégia de testes bem-sucedida que possa ser escalonada entre equipes, projetos e ferramentas de testes.

Testkube fornece uma solução holística para esses desafios, mantendo a compatibilidade com qualquer ferramenta de teste, fluxo de trabalho ou pipeline já implantado em sua organização. Uma versão de código aberto está disponível. Experimente testkube.io/get-started para levar a execução automatizada de testes para o próximo nível.

A postagem Pare de executar testes com sua ferramenta CI/CD apareceu pela primeira vez em The New Stack.