Melhore a velocidade do desenvolvedor descentralizando os testes

Conforme discuti em um artigo recente, os testes centralizados interferem na velocidade do desenvolvedor. Num modelo liderado por microsserviços, os testes centralizados tornaram-se uma espécie de “ponto crítico” para os processos de lançamento, uma vez que o desenvolvimento de código e a gestão de operações de produção foram efetivamente democratizados e as suas funções isoladas em equipas mais pequenas. A questão não é de ferramentas ruins. Na verdade, as ferramentas de teste modernas oferecem às equipes habilidades incríveis para detectar problemas que anteriormente teriam sido descobertos pelos usuários finais. O problema é que muitos problemas não são descobertos antes do teste final de ponta a ponta (E2E) e de aceitação.

Isso é compreensível, pois as interdependências modernas de microsserviços e as dependências de APIs externas tornam mais difícil do que nunca simular como o código será executado na produção. Embora os testes de pré-produção na preparação devam ser a fase em que apenas falhas raras e emergentes são detectadas, muitas vezes agora é a fase em que você obtém a primeira indicação clara sobre se o código funciona. Lembro-me de quando o teste era o local mais confiável para executar código, já que apenas versões bem avaliadas eram executadas lá – e não tínhamos problemas de escala de produção. Mas, ao ler as preocupações expressas nos fóruns Reddit r/qualityassurance e r/softwaretesting, parece que para muitas equipes a preparação se tornou extremamente não confiável, já que muitos lançamentos estão atrasados ​​por defeitos.

6 razões pelas quais os testes centralizados diminuem a velocidade do desenvolvedor

Os testes centralizados podem prejudicar significativamente a velocidade do desenvolvedor. Vamos analisar os problemas associados a essa abordagem.

• Implantações em lote na preparação: Quando alterações de código de várias equipes ou microsserviços são agrupadas em lote e implantadas em um ambiente de teste, isso cria um gargalo. Essa abordagem atrasa a integração de novo código, dificultando a identificação de qual alteração causou um problema, caso surja um problema.
  

  É por isso que o processamento em lote está rapidamente se tornando a norma.

   

• Frequência de teste e congelamentos de commits: Se o lote for testado com pouca frequência e novos commits forem desativados durante esse período, isso causará um atraso significativo no ciclo de feedback. Os desenvolvedores precisam esperar mais para ver o desempenho de suas alterações em um ambiente quase real, retardando o processo geral de desenvolvimento.
• Teste de ponta a ponta: Quando os testes E2E são conduzidos apenas por uma equipe de controle de qualidade, muitas vezes eles se transformam em testes de caixa preta. Não saber como o sistema subjacente funciona significa que os prováveis ​​pontos de falha não são testados tão minuciosamente quanto poderiam. Embora os testes E2E sejam cruciais, contar apenas com uma equipe de controle de qualidade para isso pode criar uma desconexão entre o que é desenvolvido e o que é testado.
• Processos de relatório e resolução de bugs: Quando bugs são encontrados, eles precisam ser arquivados formalmente e, em seguida, os desenvolvedores devem reproduzi-los e corrigi-los. Este processo é inerentemente lento. O tempo necessário para registrar, atribuir, reproduzir, corrigir e testar novamente os bugs pode ser substancial, especialmente se o bug for elusivo ou intermitente. Além disso, com o problema da caixa preta mencionado acima, os engenheiros que executam os testes só podem descrever o comportamento sem ter conhecimento do sistema subjacente. Isso adiciona atrito ao processo de relatório de bugs.
• Testes tardios de aceitação de recursos: Quando o teste de aceitação de recursos acontece no final do ciclo de desenvolvimento, pode levar a grandes atrasos. Se o feedback ou as alterações necessárias surgirem neste estágio, isso poderá significar um retrabalho significativo para os desenvolvedores. Isso não apenas retarda o lançamento do recurso atual, mas também afeta os cronogramas de desenvolvimento de outros recursos.
• Atrasos cumulativos e moral reduzido: Esses atrasos podem se acumular, levando a ciclos de lançamento mais longos. Isso não só afeta os negócios, atrasando o tempo de lançamento no mercado, mas também pode reduzir o moral da equipe de desenvolvimento. Os desenvolvedores geralmente preferem ciclos de feedback rápidos e ver seu trabalho em produção o mais rápido possível.

Embora eu ache importante listar essas desvantagens, não acho que alguém apoie explicitamente “testes altamente centralizados” ou “testes que acontecem apenas em ambientes de preparação/teste”. Ninguém pretende quebrar a confiabilidade dos testes unitários e E2E dos desenvolvedores, mas a complexidade de emular um cluster de produção para cada desenvolvedor produziu esse resultado. (Meu artigo anterior descreve em detalhes como esse sistema evolui.)

Como descentralizar os testes novamente

O que queremos é mudar os testes para a esquerda: permitir que testes realistas comecem logo no estágio de pull request (PR), em vez de esperar para fazê-los quando uma equipe separada estiver trabalhando com nosso código. Em equipes como Uber, DoorDash e Lyft, os engenheiros de plataforma criaram ferramentas para permitir que os desenvolvedores testem mais cedo em um ambiente mais realista. Nessas empresas, a solução não é mexer no chamado “ambiente de desenvolvedor” que nunca representa realmente a realidade, mas sim dar a todos os usuários acesso a um único cluster compartilhado que é mantido muito próximo do estado de Produção.

Especificamente, esses engenheiros de plataforma estão usando o isolamento de solicitações para permitir que uma única versão de teste de um serviço (ou um conjunto de serviços, se necessário) interaja com um cluster sem colidir com os experimentos de outros. Na Uber, esse sistema é chamado SLATE e isola os serviços de teste, permitindo que eles interajam com solicitações especialmente marcadas, enquanto dependem de serviços de produção. (Sim, isso permite que a Uber Engineering faça testes em produção, mas tem muitas salvaguardas.)

Independentemente de como for implementado, esse sistema permite que os desenvolvedores testem seu código em relação a outras dependências do cluster no início do processo de replicação. Nos anos anteriores, essa capacidade estava aberta apenas a equipes empresariais com equipes grandes e dedicadas de engenharia de plataforma. Com um serviço como o Signadot, é possível que grandes equipes implementem o isolamento de solicitações e testem turnos com um conjunto padrão de ferramentas para isolar solicitações.

Isso também pode levar a mudanças culturais dentro de uma organização: capacitadas para executar testes E2E e de aceitação mais cedo, as equipes de desenvolvimento podem integrar conhecimentos que antes estavam concentrados nas equipes de controle de qualidade. Podemos até ver os engenheiros de controle de qualidade mudando para a esquerda, à medida que ajudam os engenheiros de produto a testar mais coisas, com mais precisão e mais cedo.

5 benefícios dos testes descentralizados

Um sistema de isolamento de solicitações para experimentação de desenvolvedores envolve um aumento técnico significativo e não é tão simples quanto implantar alguns pacotes de código aberto. Também requer integração com ferramentas de CI/CD. Este não é o foco deste artigo, mas menciono-o porque vale a pena listar os benefícios antes de embarcar nesta jornada.

• Testes anteriores contra dependências precisas: Em vez de tentar replicar alguma versão do cluster, um cluster compartilhado com isolamento de solicitação permite que cada equipe teste de forma independente com a versão mais atualizada e estável do trabalho de outras equipes.
• Teste de caixa branca: Com os desenvolvedores testando o código que escreveram, eles podem entender mais rapidamente o que pode estar causando problemas, e seu conhecimento do que mudou torna mais fácil saber onde concentrar os testes.
• O teste pode abranger tipos: Testes funcionais e não funcionais podem ser executados ao mesmo tempo, como testes de aceitação executados juntamente com monitoramento de vazamento de memória, uso de CPU e testes de desempenho.
• Os desenvolvedores podem agrupar PRs conforme necessário: Um serviço como o Signadot permite selecionar vários PRs para trabalhar. Portanto, se a Equipe A e a Equipe B tiverem alterações síncronas, ambas poderão ser testadas juntas antes que o controle de qualidade seja envolvido.
• Sem registro de bug: Esse benefício suave e intangível é realmente um dos maiores aumentos na produtividade do desenvolvedor. Sem a necessidade de documentar manualmente cada problema e enviá-lo para outra equipe, o desenvolvedor que escreveu o recurso pela primeira vez pode trabalhar na correção do bug imediatamente.

Uma abordagem de teste descentralizada mais recente que coloca clusters mais precisos nas mãos dos desenvolvedores tem uma série de vantagens que levam a uma melhor velocidade de desenvolvimento e a uma equipe mais feliz.

O objetivo não é “consertar” os testes, mas melhorar gradativamente a qualidade

Embora haja uma vantagem na implementação de um sistema como o isolamento de solicitações, ele tem uma enorme vantagem em relação a fazer alterações em uma arquitetura de cluster ou em ambientes onde o código é testado e executado: é possível adotá-lo de forma incremental. Pense nisso: antes da produção, cada equipe de engenharia tem um cluster altamente preciso, mas eles não querem quebrar enviando código experimental para os serviços. Com isolamento de solicitações e roteamento inteligente de solicitações, é possível testar PRs neste cluster, mesmo que apenas sua equipe tenha acesso a tal sistema. Você não quebrará o cluster subjacente com seus experimentos, portanto, pequenos grupos podem experimentar esse sistema antes de ele ser implementado para toda a equipe.

Como a Signadot pode ajudar

Signadot permite validar cada alteração de código de forma independente. Ao conectar-se aos PRs no seu controle de origem, cada PR pode obter um espaço isolado de solicitação dentro do seu cluster para testar como essa nova versão interagirá com o restante do cluster.

Se quiser saber mais, compartilhar comentários ou conhecer a incrível comunidade que já usa o isolamento de solicitações para acelerar os fluxos de trabalho dos desenvolvedores, junte-se à comunidade Signadot Slack para se conectar com a equipe.

A postagem Melhore a velocidade do desenvolvedor descentralizando os testes apareceu pela primeira vez em The New Stack.