Quem deve realizar testes? Sobre o futuro do controle de qualidade

Isso faz parte de uma série contínua. Leia as partes anteriores:

• Por que mudamos os testes para a esquerda: um ciclo de desenvolvimento de software que não pode ser escalonado
• Por que o teste de mudança foi deixado, parte 2: o controle de qualidade faz mais depois que os desenvolvedores executam os testes
• Como mudar os testes para a esquerda: 4 modelos táticos
• Mudando o teste para a esquerda: a solução de isolamento de solicitação

Controle de qualidade é uma coisa engraçada. Isso significou tudo, desde “o engenheiro mais experiente que coloca a marca final em todo o código” até “o cara que simplesmente clica aleatoriamente e vê se alguma coisa quebra”. Já vi o controle de qualidade operando em todos os diferentes níveis da organização, desde engenheiros fortemente integrados a cada equipe até uma organização independente, quase externa.

Uma questão básica quando olhamos para a mudança de testes para a esquerda, à medida que atribuímos mais responsabilidades aos testes às equipes de produto, é qual deve ser o papel do controle de qualidade neste novo arranjo. Isso pode ser generalizado como “quem deve possuir os testes?” A Microsoft aposentou sua posição de “engenheiro de software dedicado em teste” (SDET) em 2014, enquanto a Apple e a Amazon mantêm um grande foco no controle de qualidade dedicado. Se as empresas FAANG não conseguem decidir se precisamos de funções dedicadas de controle de qualidade, como o restante de nós pode responder a essa pergunta?

Vamos explorar como o papel do controle de qualidade cresce em um mundo onde os testes estão mudando para a esquerda.

O controle de qualidade tem sido vítima de tendências há muito tempo, mas o controle de qualidade continua

Em minha primeira função técnica na New Relic, conheci todas as equipes de engenharia que criaram agentes APM (gerenciamento de desempenho de aplicativos) para as principais linguagens de desenvolvimento web. Cada equipe tinha uma composição semelhante, mas perguntei: “Quem é o responsável pelo controle de qualidade da equipe Ruby?”

“Não existe”, respondeu o chefe da equipe Ruby. “Rails não requer controle de qualidade.”

A arrogância dessa equipe pode ser perdoada: nunca há uma nova linguagem popular em cena sem que alguém insista que ela resolva todos os problemas de software conhecidos e torne impossíveis bugs, falhas e comportamentos inesperados. No entanto, essa conversa me levou a um princípio mais geral: alguns sempre veriam o controle de qualidade como algo embaraçoso de se precisar, o que significa que algumas equipes proclamariam com orgulho que não precisavam mais de pessoas dedicadas a testes.

Na década desde esta conversa, ficou claro que nenhuma linguagem ou estrutura está livre da necessidade de testes. Esse trabalho pode ser altamente distribuído, com cada engenheiro fazendo o melhor para escrever testes, executá-los e interpretar os resultados. Alternativamente, o trabalho pode ser centralizado, com alguns selecionados executando um conjunto completo de testes em cada versão.

Nunca houve um tempo em que os desenvolvedores não executassem testes

“Antigamente, o controle de qualidade era responsável por executar todos os testes e os desenvolvedores apenas escreviam o código.” Isso nunca foi verdade. Desde a era de figuras inovadoras como Grace Hopper, os desenvolvedores sempre foram capazes de executar o código que estavam escrevendo, e ninguém entregou código realmente não testado ao controle de qualidade. Todos nós adicionamos instruções de depuração, verificamos as saídas de log do console e clicamos em uma interface em execução no host local. Se estamos mudando os testes para a esquerda agora, isso não significa que os desenvolvedores executarão testes pela primeira vez.

Em vez disso, mudar para a esquerda significa dar aos desenvolvedores acesso a um conjunto completo de testes altamente precisos e, em vez de apenas adivinhar, a partir de sua compreensão dos contratos de API e de alguns testes unitários, que seu código está funcionando, queremos que os desenvolvedores estejam realmente confiantes de que estão entregando desligue o código funcional antes de implantá-lo na produção.

O controle de qualidade não deveria testar códigos que os desenvolvedores não testaram

É um princípio simples e evidente que quando o controle de qualidade encontra um problema, isso deve ser uma surpresa para os desenvolvedores. Se os desenvolvedores estiverem enviando código para teste e não tiverem ideia se funciona, haverá uma série de bugs simples e facilmente detectados que poderiam ter sido resolvidos em um dia que agora passará uma semana a mais aguardando o ciclo de feedback do loop externo .

Tudo isso pode parecer evidente, mas quando se trata de testes de integração — vendo como seu código realmente funciona em relação aos outros serviços e dependências em sua pilha — muitas organizações ainda dependem de uma equipe separada para executar testes nesse nível. Sem acesso a testes de integração completos e precisos, quando um desenvolvedor envia uma solicitação pull, ele está criando uma situação onde muitas surpresas o aguardam.

Não é mais separado: controle de qualidade integrado nas equipes

Em vez de uma equipe de controle de qualidade separada que supervisiona o código antes do lançamento para produção, uma abordagem que pode funcionar bem em um ambiente de microsserviço é incorporar profissionais de controle de qualidade e/ou SDETs nas equipes.

Os profissionais de controle de qualidade integrados às equipes não devem apenas executar testes; suas responsabilidades se estendem à criação de conjuntos de testes abrangentes e à identificação de regressões em todo o serviço. Essa abordagem proativa garante que a qualidade seja mantida em toda a base de código. Não deve ser um engenheiro quem testa o código do qual está muito próximo; é mais eficaz quando um controle de qualidade dedicado o avalia objetivamente.

Um valor chave que o controle de qualidade traz é avaliar a testabilidade de uma base de código. Ao se concentrarem no encapsulamento da lógica de negócios, os profissionais de controle de qualidade facilitam os testes e contribuem para uma arquitetura mais robusta. Por exemplo, esta abordagem permite trocar serviços de banco de dados conforme necessário para otimização financeira, além de apenas melhorar a testabilidade.

Num ambiente baseado em microsserviços onde as equipas possuem microsserviços individuais, os profissionais de QA desempenham um papel crítico na supervisão das interações entre estes serviços. As equipes individuais geralmente se concentram em seus microsserviços específicos, potencialmente ignorando as interações mais amplas do sistema, onde os problemas surgem com frequência. Ao atuar como uma entidade separada, o controle de qualidade pode avaliar holisticamente a arquitetura, garantindo uma cobertura abrangente de testes e auxiliando as equipes na inicialização de seus esforços de teste.

O que o controle de qualidade faz agora

A mudança, então – à medida que o controle de qualidade se incorpora às equipes e mais desenvolvedores sabem como executar testes de alta qualidade – é que o controle de qualidade acaba fazendo mais, e não menos. O trabalho realizado pelo controle de qualidade torna-se mais estratégico e tem um efeito maior na velocidade geral do desenvolvedor. Coisas como:

• Elaborando a estratégia de teste
• Construindo estruturas de teste
• Escolhendo as ferramentas de teste certas
• Foco em automação ponta a ponta mais complexa
• Mudando para a esquerda e incorporando-se às equipes de produto para permitir testes antecipados

À medida que cresce a necessidade de velocidade de desenvolvimento e implantações confiáveis, o controle de qualidade se tornará mais valioso do que nunca.

Junte-se ao Signadot Slack

Na Signadot, tentamos facilitar os testes em todas as partes do ciclo de vida de desenvolvimento de software. Se você estiver interessado em saber mais, junte-se a nós no Slack para conhecer nossa comunidade.

O post Quem deve realizar testes? Sobre o futuro do controle de qualidade apareceu pela primeira vez em The New Stack.