Testes automatizados para CI/CD

Testes são essenciais para garantir a qualidade do software e há muito faz parte das práticas de desenvolvimento de software.

No contexto de um processo cascata, o teste manual ou estágio de QA ocorre depois que o código foi desenvolvido e integrado, tendo como objetivo verificar se a aplicação se comporta de acordo com a especificação.

Essa abordagem linear retarda o processo de lançamento e significa que seus desenvolvedores não terão como saber se o que eles criaram funciona como esperado até muito mais adiante, depois que muito mais tempo foi gasto construindo código baseado nele. Por outro lado, um processo de automação de CI/CD permite uma abordagem ágil de ciclos iterativos curtos que fornecem feedback rápido e permitem que as atualizações sejam lançadas com frequência e tamanho reduzido. Uma parte importante desses ciclos curtos e iterativos é o processo de testes para validar automaticamente se o novo código funciona e se não causou problemas em outras partes do código.

A integração contínua envolve a submissão de alterações de código no mestre ou tronco regularmente, acionando uma compilação, se aplicável, e garantindo a qualidade do software todas as vezes. Para realmente colher os benefícios da CI, os membros de sua equipe devem ter como objetivo fazer commit das alterações pelo menos diariamente. No entanto, mesmo em equipes pequenas, testes manuais de automação com essa frequência demandariam um esforço considerável dos engenheiros de QA e seria um trabalho bastante repetitivo. É aqui que entram os testes automatizados.

A resposta é que testes ocorrem em múltiplos estágios ao longo de todo o pipeline.

Se você é novo em integração e implantação contínuas, isso pode parecer um exagero, mas a automação de CI/CD e o controle de qualidade têm tudo a ver com ciclos de feedback rígidos que permitem que sua equipe descubra problemas o mais cedo possível.

É muito mais fácil corrigir um problema logo depois dele ter sido introduzido, pois isso evita que mais código seja escrito em cima de um fundamento ruim. Também é mais eficiente para sua equipe fazer alterações antes de passar para a próxima tarefa, perdendo o contexto.

Muitas ferramentas automatizadas de teste de compilação oferecem suporte à integração com ferramentas de CI/CD, então é possível alimentar os dados de teste no pipeline e realizar testes em etapas, com resultados fornecidos após cada etapa. Dependendo de sua ferramenta de CI, você também pode escolher se deseja mover um build para a próxima etapa com base no resultado dos testes no passo anterior.

Para obter o máximo de seu pipeline por meio de testes automatizados, geralmente faz sentido ordenar seus testes de compilação de forma que os mais rápidos sejam executados primeiro. Assim você recebe feedback mais cedo e aproveita de forma mais eficiente os ambientes de teste, já que pode garantir que os testes iniciais passaram antes de executar testes mais longos e complexos.

Ao considerar como priorizar a criação e a execução de testes automatizados, é útil pensar em termos da pirâmide de testes.

A pirâmide de testes é uma maneira prática de conceituar como priorizar testes de integração contínua em um pipeline de CI/CD, tanto em termos de número relativo quanto na ordem em que são executados.

Definida originalmente por Mike Cohn, a pirâmide de testes coloca os testes de unidade na base da pirâmide, testes de serviço no meio e testes de interface do usuário na ponta.

Embora a nomenclatura possa não ser precisa, a premissa é clara: comece com uma base sólida de testes de unidade automatizados que sejam rápidos e fáceis de executar, antes de avançar para testes mais difíceis de escrever e que demoram mais para executar. Por fim, termine com uma pequena quantidade dos testes mais complexos. Que tipos de testes de CI/CD você deve considerar? Vamos explorar as alternativas.

O objetivo de executar testes automatizados como parte de sua prática de CI/CD é obter um feedback rápido sobre as alterações que você acabou de fazer, portanto, ouvir e responder a esse feedback é fundamental.

Servidores de CI normalmente são integrados com ferramentas de teste automatizadas para que você possa exibir todos os resultados em um só lugar. Equipes de desenvolvimento geralmente combinam um painel ou radiador de informações contendo os resultados mais recentes com envio de notificações automatizadas a plataformas de comunicação, como o Slack, para mantê-los informados sobre o desempenho do último build.

Quando um teste falha, entender a qual parte da base de código ele está associado e ser capaz de visualizar qualquer informação produzida pelo teste, como um stacktrace, valor de saída ou captura de tela, pode acelerar o processo de descoberta da causa raiz. Vale a pena dedicar tempo para projetar testes cuidadosamente, de modo que cada um verifique uma única coisa, e rotulá-los especificamente para que você possa entender o que falhou. Testes de integração contínua e as ferramentas de CI que fornecem informações adicionais sobre falhas de teste também podem ajudar você a recuperar suas compilações com mais rapidez.

Como sempre, ferramentas e práticas são apenas uma parte da equação. Uma prática de automação de CI/CD realmente boa requer uma cultura de equipe que reconheça não apenas o valor dos testes automatizados de CI/CD, como também a importância de responder rapidamente a testes com falha para manter o software em um estado implementável.

Um equívoco comum entre aqueles que são novos em CI/CD é que os testes automatizados evitam a necessidade de testes manuais e de engenheiros profissionais de controle de qualidade.

Embora a automação de CI/CD libere algum tempo para os membros da equipe de controle de qualidade, ela não os torna redundantes. Em vez de perderem tempo em tarefas repetitivas, os engenheiros podem se concentrar em definir casos relativos, escrever testes automatizados e aplicar sua criatividade e engenhosidade a testes exploratórios.

Ao contrário dos testes de compilação automatizados, que são cuidadosamente programados para execução por um computador, os testes exploratórios requerem apenas uma missão solta. O valor de um teste exploratório está em encontrar coisas que testes planejado e bem estruturados não conseguem achar. Basicamente, você está procurando problemas que ainda não foram considerados e para os quais ainda não foram escritos casos de teste. Ao decidir quais áreas a serem exploradas, considere tanto novas funcionalidades e áreas de seu sistema que causariam mais danos se algo desse errado durante a produção.

Testes exploratórios não devem se transformar em testes manuais e repetitivos; a intenção não é executar o mesmo conjunto de testes todas as vezes. Quando problemas são descobertos durante um teste exploratório, além de corrigi-los, reserve um tempo para escrever um teste automatizado para que, se o problema ocorrer novamente, ele seja detectado numa fase inicial do processo. Para aproveitar o tempo dos testadores de forma eficiente, um teste manual só deve ocorrer depois que todos os testes automatizados tiverem sido executados com sucesso.

Testes automatizados exercem um papel fundamental em qualquer pipeline de CI/CD.

Embora a criação de testes automatizados necessite um investimento de tempo e esforço, os benefícios do feedback rápido e da possibilidade de saber quanto o código está pronto para ser colocado em operação significa que os testes automatizados se pagam rapidamente. Mas construir uma suite de testes não é algo que você faz uma vez e esquece.

Seus testes de compilação automatizados devem fazer parte do seu aplicativo tanto quanto o restante do seu código e, portanto, precisam ser mantidos para garantir que permaneçam relevantes e úteis. Como tal, a melhoria contínua que você está sempre aplicando ao seu código também deve ser aplicada aos seus testes.

Continuar a construir uma cobertura de testes automatizados para novos recursos e alimentá-los com as descobertas dos testes exploratórios irá manter sua suite de testes eficaz e eficiente. Também vale a pena reservar um tempo para ver como está o desempenho e se vale a pena reordenar ou dividir as etapas do seu trabalho para obter feedback mais cedo.

Através das ferramentas de CI você pode obter diversas métricas que irão ajudá-lo a otimizar seu pipeline, enquanto indicadores de testes instáveis podem indicar testes não confiáveis que poderão passar uma falsa confiança ou preocupação. Mas embora métricas possam lhe ajudar a melhorar seu processo de testes automatizados, evite a armadilha de pensar que a cobertura do teste é um objetivo em si. O verdadeiro objetivo é entregar, com regularidade, um software que funciona para seus usuários. A automação atende a esse objetivo, fornecendo feedback rápido e confiável para que você possa ter confiança ao implantar seu software no ambiente de produção.