Por que o teste de mudança foi deixado, parte 2: o controle de qualidade faz mais depois que os desenvolvedores executam os testes

Esta é a segunda de duas partes. Leia a Parte 1.

Em meu artigo anterior, falei sobre como o ciclo de vida de desenvolvimento de software (SDLC) não foi ampliado à medida que migramos para arquiteturas de microsserviços. O resultado foi um processo mais parecido com uma cascata, onde todos aguardam um processo de controle de qualidade e o feedback só chega aos desenvolvedores lentamente. A solução proposta é “mudar para a esquerda”: capacitar mais desenvolvedores para executar e manter testes.

O controle de qualidade ainda tem uma função

É razoável perguntar se mudar os testes para a esquerda significa que os engenheiros de controle de qualidade ficarão desempregados. Nada poderia estar mais longe da verdade. Quando especialistas altamente técnicos da sua equipe têm parte de suas responsabilidades transferidas devido a mudanças no design, o resultado é que esses especialistas acabam fazendo mais, e não menos, com maiores expectativas sobre o que podem possibilitar.

“Quem aqui ainda configura servidores de e-mail?”

Há alguns anos, eu estava ouvindo uma palestra de Kelsey Hightower, onde ele defendia a mudança para ferramentas de hospedagem gerenciadas em nuvem pública e sem servidor em vez de máquinas virtuais gerenciadas diretamente. Alguém na plateia perguntou: “Vocês querem que os administradores de sistemas percam seus empregos?”

Kelsey teve uma resposta perspicaz. “Todos nesta sala”, disse ele, “levantem a mão se vocês costumavam configurar servidores de e-mail, seus certificados e autenticação”.

Cerca de 80% da sala levantaram a mão.

“Agora mantenha a mão levantada se você ainda trabalha mantendo essa configuração para servidores de e-mail.”

Ninguém manteve as mãos levantadas. Estou parafraseando aqui, mas este foi o cerne do que ele disse a seguir:

“Todos vocês têm muita experiência em administração de sistemas. E quando surge um serviço que elimina parte desse trabalho, o resultado normal não é que todos trabalhem menos; é que esperamos mais. Em vez de solicitar a ativação de um novo servidor e esperar pelo menos um dia para implantá-lo, agora esperamos que as máquinas virtuais apareçam automaticamente com alterações de configuração. Não me fale sobre o escalonamento automático de cluster.”

A questão foi bem entendida: quando se elimina o trabalho de uma equipe qualificada, o resultado são maiores expectativas e não redução da carga de trabalho. É o trabalho pesado arbitrário que é eliminado, não as pessoas.

Pense no que aconteceu com muitos administradores de sistemas nos últimos anos: antes eram encarregados de configurar e gerenciar manualmente dezenas de servidores, agora as mesmas pessoas orquestram centenas ou milhares de contêineres. Embora ninguém mais configure servidores de e-mail, nossas expectativas sobre o que essas mesmas pessoas podem fazer só aumentaram.

Controle de qualidade como líder estratégico

O objetivo de mudar os testes para a esquerda não é remover o controle de qualidade, é permitir que o controle de qualidade seja um líder estratégico que ajuda a padronizar a cultura em torno dos testes, mantém a automação para que tudo funcione sem problemas e escolhe estruturas e padrões para testes para que os resultados possam ser compartilhados. Pense em uma equipe de controle de qualidade que possa:

• Ajudar a selecionar e manter atualizados os frameworks de testes para diferentes áreas da aplicação
• Definir estratégia de testes e quais novos recursos exigem novos testes
• Monitore “cruft”, como testes com falha de longa data ou testes com feedback ruim, e trabalhe na dívida técnica que melhorará a experiência de cada desenvolvedor
• Adicione cobertura de teste para casos extremos conhecidos, riscos de segurança e falhas de privacidade para garantir que seu código permaneça em conformidade.

Sem falhas constantes na fusão, o controle de qualidade pode se concentrar em encontrar comportamentos emergentes e regressões que os testes automatizados não teriam percebido. O controle de qualidade também pode dedicar algum tempo para aprender os tipos de testes que as equipes de desenvolvimento mais precisam, definir práticas que façam com que a escrita dos testes demore menos tempo e otimize os executores de testes para fazer com que a execução dos testes leve menos tempo, acelerando o ciclo de feedback interno do desenvolvedor.

Controle de qualidade incorporado: sempre vale a pena pensar

No meu primeiro trabalho técnico, cada equipe linguística tinha um especialista em controle de qualidade e um especialista em documentação. Lembro-me disso porque as únicas exceções eram Ruby e Java. Ruby não tinha controle de qualidade porque “Rails não requer controle de qualidade”. Java não tinha redator de tecnologia porque “Java é autodocumentado”. Que tolos éramos! Mas a ideia básica de incorporar o controle de qualidade em suas equipes ainda é poderosa.

Há todos esses anos, os especialistas em controle de qualidade usavam alguma automação, mas também eram mestres em exercitar seus produtos manualmente para encontrar falhas. Em retrospecto, subestimamos a necessidade de controle de qualidade e documentação em todos os idiomas. A crença de que Ruby on Rails não exigia controle de qualidade ou que Java era autodocumentado parece ingênua agora.

Hoje em dia é ainda mais crucial considerar o controle de qualidade incorporado, especificamente engenheiros de desenvolvimento de software em teste (SDETs). A ideia é incorporar SDETs nas equipes de produto que podem possuir automação. SDETs concentram-se exclusivamente em escrever testes automatizados e, por serem incorporados em cada equipe de produto, eles também reconhecem o domínio e podem escrever testes significativos.

Conclusão: Mudar para a esquerda é um retorno aos bons velhos tempos

A motivação para mudar para a esquerda decorre principalmente do desejo de aumentar a velocidade de desenvolvimento e reduzir a frequência de bugs que chegam à produção.

Para as empresas em crescimento, a complexidade dos sistemas, especialmente com microsserviços, acrescenta outra camada de desafio. O método tradicional de desenvolvedores escreverem código e confiarem no controle de qualidade para detectar problemas posteriormente não é dimensionado de forma eficiente à medida que a empresa cresce.

A opção de mudar os testes para a esquerda oferece uma solução ao capacitar os desenvolvedores a realizar testes mais abrangentes – incluindo integração e até mesmo testes ponta a ponta – no início do processo de desenvolvimento. Esta mudança restabelece um sentimento de propriedade e satisfação entre os desenvolvedores, pois eles podem verificar seu trabalho imediatamente e enviar solicitações pull com mais confiança.

Essa mudança não diminui o papel do controle de qualidade, mas o transforma. O controle de qualidade passa a ser mais uma questão de liderança de estratégia, definição e manutenção de estruturas de automação e garantia de qualidade em todo o processo de desenvolvimento. Mudar os testes para a esquerda não é apenas um retorno a práticas de desenvolvimento mais eficientes, reminiscentes de tempos anteriores, quando os sistemas eram mais simples e podiam ser testados de forma mais direta, mas é uma adaptação necessária às complexidades do desenvolvimento de software moderno. Esta mudança visa melhorar a velocidade e a qualidade dos lançamentos de software, essencial para empresas que procuram escalar de forma eficaz sem comprometer a qualidade.

Conecte-se com Signadot

Na Signadot, estamos tentando construir as ferramentas que sua equipe precisa para permitir que cada desenvolvedor teste seu código em um cluster altamente preciso com menos surpresas no momento da implantação. Veja como possibilitamos testes de alta fidelidade.

A postagem Por que o teste de mudança saiu, parte 2: o controle de qualidade faz mais depois que os desenvolvedores executam os testes apareceu pela primeira vez em The New Stack.