Por que mudamos os testes para a esquerda: um ciclo de desenvolvimento de software que não pode ser escalonado

Esta é a primeira de duas partes.

O teste de deslocamento para a esquerda é a prática de mover o teste no início do processo de desenvolvimento. Num ciclo de desenvolvimento tradicional, o teste geralmente ocorre após a conclusão de um recurso ou mesmo no final da fase de desenvolvimento. O teste Shift left desafia isso integrando atividades de teste desde o início e durante todo o processo de desenvolvimento.

Vamos começar discutindo por que escolhemos a opção de deslocamento para a esquerda, já que não é a única maneira de resolver problemas de dimensionamento com seu ciclo de vida de desenvolvimento de software (SDLC).

Uma história tão antiga quanto o tempo: um SDLC que não escala

Antes de decidirmos passar mais testes para o lado de desenvolvimento do processo, vamos discutir por que os líderes tomariam essa decisão em primeiro lugar.

Há uma leitura cínica de “mudança para a esquerda” que é “fazer as pessoas trabalharem mais, mas pagar-lhes o mesmo”. Uma equipe de desenvolvimento estressada pode se rebelar diante da ideia de adicionar mais preocupações à sua agenda. Mas a verdadeira motivação para mudar os testes para a esquerda é a frustração com um ciclo de lançamento de software em impasse, os desenvolvedores forçados a mudar de contexto e nunca autorizados a entrar em um estado de fluxo e uma velocidade de desenvolvimento glacial.

Uma empresa em expansão cujo processo de teste não é

Imagine que você está em uma empresa que está crescendo além do estágio inicial. Todos vocês se lembram de uma época em que os recursos eram lançados em semanas ou até dias, mas esses dias já se foram. Agora, várias equipes estão tentando lançar ramificações ao mesmo tempo, e o controle de qualidade está estressado tentando encontrar problemas antes de lançá-los para produção.

Pior ainda, a complexidade da arquitetura de microsserviços significa que os desenvolvedores não podem realizar testes de integração com eficácia antes de enviar o código para controle de qualidade. Fala-se muito sobre como melhorar os testes de contratos, mas, novamente, as coisas estão crescendo rapidamente e as estimativas para escrever contratos intra-serviços claros e refatorar para corresponder levariam meses. Enquanto isso, os desenvolvedores ficam presos na escrita de testes unitários e na criação de simulações grosseiras para serviços externos, como provedores de pagamento e até mesmo serviços de outras equipes. Isso leva a mais surpresas quando o código é implantado em ambientes de pré-lançamento, como teste.

A escolha de mudar os testes para a esquerda

Portanto, nossos líderes de engenharia enfrentam uma escolha: como melhorar a velocidade do desenvolvedor e ao mesmo tempo enviar menos bugs para a produção? Você tem duas opções:

• Aumente a equipe de controle de qualidade e expanda os recursos para seu ambiente de teste/preparação, para que eles possam fazer mais testes com mais rapidez.

Esta não é uma escolha terrivelmente escalonável. As equipes já estão ocasionalmente em conflito sobre quem implantará o ambiente de teste e por quanto tempo elas precisam para ter o ambiente reservado. Além disso, mesmo com mais engenheiros de controle de qualidade, você ainda faz os desenvolvedores escreverem código, executarem testes limitados, enviarem push e esperarem que um ser humano responda com os problemas detectados. O resultado é um ciclo de feedback de “loop externo”, onde os desenvolvedores precisam pausar todo o trabalho até obterem feedback de controle de qualidade ou alternar o contexto entre duas ramificações enquanto tentam trabalhar no próximo recurso enquanto voltam e encontram problemas com a última coisa que enviaram . Mesmo com um orçamento ilimitado para a equipe de controle de qualidade, isso definitivamente não será dimensionado para centenas de desenvolvedores.

Aumentar o controle de qualidade não é uma alternativa para mudar para a esquerda

O controle de qualidade tem um papel importante na visão estratégica e nas decisões de arquitetura para testes, à medida que uma equipe de engenharia muda os testes para a esquerda. Mas a busca para garantir que mais lançamentos sejam bem-sucedidos não é perfeitamente atendida apenas pela expansão da equipe de controle de qualidade. Por que é que?

• Como os desenvolvedores estão fazendo apenas testes básicos antes de mesclar o código, é provável que o controle de qualidade descubra bugs triviais de integração.

Essa lista de atributos é um array ou um objeto? E esse localizador é indexado em 0 ou não? Esses pequenos erros de integração podem bloquear uma versão quando o controle de qualidade os estiver testando. Em vez de um desenvolvedor encontrar pequenos problemas com seu próprio código e corrigi-los rapidamente, o controle de qualidade agora é necessário para documentar e comunicar o problema. Pior ainda é quando o controle de qualidade não sabe com quem se comunicar:

• As equipes de controle de qualidade normalmente escrevem testes ponta a ponta que testam fluxos de negócios/usuários. Se algum desses testes falhar, não fica claro a quem atribuir o problema, pois o fluxo pode afetar vários serviços de front-end e back-end.

Como desenvolvedor, você faz atualizações em user_state_controller, mas como controle de qualidade você pode testar coisas como “o usuário pode atualizar seu login”. Isso não é um descompasso, pois as equipes têm objetivos diferentes. Mas quando o controle de qualidade encontra erros em um fluxo de usuário, ele não sabe necessariamente quem no desenvolvimento seria a melhor pessoa com quem conversar. Isso causa mais atrasos.

• A cadência de execução dos testes não é clara. O controle de qualidade deve realizar testes diariamente? Depois que cada solicitação pull é mesclada? Como o conjunto de testes provavelmente será grande, é impraticável executar todo o conjunto para cada commit.

Sem uma equipe de engenheiros para determinar o melhor conjunto de testes a ser executado, o controle de qualidade acaba executando testes em uma cadência reduzida e encontrando problemas apenas em grupos grandes.

• Os desenvolvedores enfrentam ciclos de depuração muito lentos quando os testes falham na fase de controle de qualidade. Quando há vários commits sendo testados juntos, não fica claro qual deles é o commit ofensivo.

Este é um detalhamento básico que acho que merece mais discussão: executar um grande conjunto de testes por uma equipe de controle de qualidade é uma maneira atraente de garantir que tudo esteja funcionando conforme planejado, de ponta a ponta. Mas os testes de alta fidelidade também precisam ser de alta frequência. Caso contrário, perderemos os benefícios básicos do controle de origem: sem testes em execução para cada commit, perderemos reversões e correções fáceis. Esta é uma das muitas maneiras pelas quais o teste “shift left” é um retorno a um padrão mais antigo: os desenvolvedores devem ser capazes de saber imediatamente se seu grupo atual de alterações quebrou alguma coisa. Confiar no controle de qualidade para encontrar problemas na primeira vez significa que você está escolhendo uma longa lista de falhas tentando determinar quais foram causadas por qual commit.

• Esse processo então se torna mais um modelo em cascata, onde desenvolvimento e controle de qualidade são fases distintas e sequenciais. Isso é o oposto de uma abordagem ágil que traz benefícios óbvios.

Novamente, estamos falando de uma regressão dos padrões de codificação e entrega de 2005. O modelo em cascata torna impossível fazer uma verdadeira entrega contínua para a produção.

Uma ideia essencial aqui é que o controle de qualidade, sendo o único localizador de bugs, enfraquece seus engenheiros.

Capacitando seus engenheiros

Mesmo sem as preocupações do nível de liderança sobre o impacto na velocidade, você pode imaginar que uma configuração em que a maior parte do feedback vem do circuito externo pode ser frustrante e dolorosa para os engenheiros. Deixando meu ego de lado, não quero forçar códigos nos quais tenho pouca confiança. Isso nos leva à opção dois:

• Mudar os testes para a esquerda dá aos desenvolvedores o poder de executar testes de integração ou até mesmo de ponta a ponta poucos minutos depois de escrever seu código e garantir que nada esteja sendo submetido ao controle de qualidade para pré-lançamento sem 95% de certeza de que tudo está funcionando.

Nesse cenário, quebrar coisas como desenvolvedor pode ser divertido novamente: estamos experimentando, vendo o que os outros serviços podem suportar e apenas empurrando o que sabemos que funciona. O controle de qualidade ainda tem um papel importante nesse design, mas seu papel é menos no teste manual e na localização de bugs individuais. Em vez disso, a equipe de QA se torna um líder estratégico na definição da estratégia de automação, selecionando estruturas de teste e permitindo que os desenvolvedores tenham mais confiança em seu código. Com testes disponíveis para todos os engenheiros todos os dias, haverá muito mais testes sendo escritos e executados, mas o feedback deles vai direto para os desenvolvedores em um ciclo interno de feedback.

Mudar os testes para a esquerda é o retorno de um sistema melhor e mais antigo

Em uma discussão recente em um grupo de café enxuto de engenharia de plataforma, uma ideia ficou na minha mente, mencionada por alguns participantes:

“Os microsserviços apresentam muitas vantagens, mas os microsserviços são muito mais difíceis de testar. Esse problema é tão grave que muitas equipes não veem benefícios reais nos microsserviços.”

Já escrevi sobre isso antes, mas para resumir: na era dos monólitos, muitas vezes havia uma maneira de executar todo o sistema, ou um fac-símile, em seu laptop com o mínimo de atrito. Isso significava que testes significativos poderiam acontecer durante o desenvolvimento.

Então, realmente, quando falamos sobre mudar os testes para a esquerda, estamos falando sobre mudar isso voltar. Ainda temos uma função para as equipes de controle de qualidade, mas queremos colocar as primeiras rodadas de testes de volta nas mãos dos engenheiros que escrevem o recurso.

O controle de qualidade ainda tem um papel importante

Na continuação deste artigo, escreverei sobre a função que o controle de qualidade tem e continuará a ter à medida que você transfere a responsabilidade de executar os testes para suas equipes de desenvolvimento. Resumindo, o controle de qualidade ainda tem um papel importante a desempenhar e fará muito mais, e não menos, quando os desenvolvedores executarem mais testes. Se você quiser discutir este artigo e as ideias do teste de deslocamento para a esquerda, junte-se a nós no Signadot Slack. Adoraríamos ouvir suas ideias!

A postagem Por que mudamos os testes para a esquerda: um ciclo de desenvolvimento de software que não escala apareceu pela primeira vez em The New Stack.