A maioria das equipes de TI exige um grande número de funções que às vezes são impossíveis de cobrir com a equipe existente. E a primeira coisa a fazer nesses casos é distribuir as tarefas entre os membros da equipe. Aqui tentaremos pensar porque a delegação de tarefas de controle de qualidade é perigosa para o seu produto.

loja habitual

Vamos imaginar que você seja um PO de um novo produto de TI em uma empresa. O produto é uma perspectiva, os concorrentes estão atrás de você, mas não tão longe e você vai contratar uma equipe o mais rápido possível. Você está pensando em todos os seus projetos anteriores, experiência anterior e decide que precisa de três desenvolvedores BE, dois desenvolvedores FE, um especialista em QA (claro com conhecimento de testes automáticos), um scrum master, um analista de negócios e um UX/UI designer. Então, após a estimativa do orçamento, você entende que o projeto não pode pagar tantos membros da equipe e você precisa decidir quem é realmente necessário.

OK, o código não pode ser escrito sozinho, então os desenvolvedores são necessários. Você decide sobreviver com 2 desenvolvedores BE e 1 desenvolvedor FE que já saiu de férias este ano.

Você pode coletar requisitos, mas sejamos honestos, você tem muitas outras coisas para fazer além de criar tarefas no Jira e manter a documentação. Portanto, pelo menos os analistas de negócios podem assumir a responsabilidade de ajudá-lo com isso.

Você não pode começar a trabalhar sem um protótipo, então você precisa de um UX/UI designer.

Todos estão altamente motivados com novos produtos, já trabalharam com scrum antes e não há necessidade de um scrum master agora.

Você já está sem orçamento, mas quem será o responsável pelos testes? Após várias discussões, você e sua equipe chegaram a um acordo mútuo de que os analistas de negócios também podem cobrir os cenários de teste no início. Mas assim que o produto crescer, contrataremos um engenheiro de controle de qualidade.

O desenvolvimento começou, vários meses se passaram e tudo funciona perfeitamente, mas as partes interessadas estão esperando por mais recursos. O UX/UI designer trabalha com antecedência, como de costume, todos os protótipos e prontos para desenvolvimento e você decide contratar mais desenvolvedores. Sim, todos se lembram que planejamos contratar QA, mas novos recursos estão chegando, é tão emocionante! Claro, você tem alguns bugs, que não são críticos e já estão acumulados, então não se preocupe.
O produto está crescendo e as partes interessadas estão felizes. O atraso técnico é maior do que o esperado, mas a maioria dos membros da equipe sabe como resolver problemas críticos e restaurar o sistema.

Bola de neve da dívida

Mas vamos pensar nesses pequenos bugs do fundo de nossa lista de pendências. Qual foi a causa raiz deles? Uma revisão de código foi feita. O analista de negócios verificou a funcionalidade. Por que eles apareceram?

Infelizmente, testes adequados não podem ser feitos em paralelo com as atividades principais. O proprietário do produto e o analista de negócios entendem os processos e podem testar a funcionalidade, mas geralmente os bugs aparecem em casos “especiais” que às vezes não são descritos nos critérios de aceitação.

Os especialistas em controle de qualidade têm esse superpoder de encontrar bugs, geralmente em alguns casos especiais. Sim, parece óbvio, mas gostaria de destacar as vantagens de longo prazo de ter o controle de qualidade em uma equipe desde o início.

Um dos problemas com bugs no sistema é que eles requerem atenção. No começo, você não tem muitos problemas, então parece que a equipe pode gerenciar os testes sem controle de qualidade. Mas a qualidade do teste é muito baixa e quando você tem milhares de linhas de código — torna-se cada vez mais complicado investigar qual local deve ser corrigido. Além disso, é mais fácil corrigir o código que você escreveu 1 dia antes do que o código escrito vários meses atrás.

Tempo de foco

Todo desenvolvedor sabe como pode ser difícil mudar de uma tarefa para outra. Algumas tarefas realmente complicadas exigem foco profundo por mais de 1 a 2 horas. Portanto, em um mundo ideal, um desenvolvedor pode se concentrar em 1 tarefa durante o dia e iniciar uma nova quando a anterior foi encerrada.

Leva algum tempo para se concentrar e o tempo mais produtivo começa após 10 a 20 minutos de uma tarefa. Portanto, podemos concordar que um aumento no foco acelera o processo de desenvolvimento.

No mundo real, é claro, temos muitos outros negócios, discussões, investigações e tarefas urgentes e é por isso que os dias de trabalho não são tão ideais quanto desejamos do ponto de vista do tempo de foco.

Ainda assim, isso não é tão ruim, claro, nosso foco está diminuindo no final do dia, mas a revisão de código e as discussões também fazem parte do nosso tempo de trabalho e não podemos evitá-lo.

Mas o que acontece quando um desenvolvedor se distrai com pequenos problemas cotidianos que não foram corrigidos no início?

• “O trabalho do cron falhou novamente, você poderia reiniciá-lo?”
• “Oh, há um erro interno do servidor, você poderia verificar os logs?”
• “O relatório está carregando por mais de 1 minuto, dê uma olhada”

Claro que na realidade estão acontecendo mais eventos durante a jornada de trabalho, mas a ideia principal é que menos foco nas tarefas significa menos qualidade e velocidade de desenvolvimento.

visão de longo prazo

Precisamos corrigir esses bugs assim que eles acontecem na produção. Mas também temos recursos regulares em andamento e não podemos perder o sprint. E toda vez que a equipe precisa tomar uma decisão: corrigir um bug antigo agora ou terminar a tarefa atual e planejar corrigi-lo no próximo sprint? A equipe tem um compromisso perante os negócios de entregar recursos no prazo e uma vez isso se torna uma história sem fim.

Esses bugs poderiam ser destacados pelo controle de qualidade no início, mas não tínhamos um responsável e a velocidade de desenvolvimento era a prioridade. E é verdade, a ausência de bugs destacados pelo controle de qualidade permite que a equipe feche os tickets mais rapidamente. Observe o diagrama abaixo:

Os desenvolvedores estão focados nas tarefas e geralmente, após a revisão do código, eles são fechados, para que possam começar a trabalhar na próxima. Mas com o tempo de ciclo de envolvimento do controle de qualidade será aumentado devido a bugs e problemas encontrados.

Mas depois de vários meses de trabalho sem testes de controle de qualidade adequados, você enfrentará mais bugs e problemas conhecidos e levará mais tempo na investigação.

Depois de anos dessa abordagem, a velocidade do sprint diminuirá drasticamente:

Torna-se cada vez mais complicado entender quantos pontos de história uma equipe pode obter em um sprint. Às vezes, é necessário interromper o desenvolvimento e passar um sprint completo no backlog técnico. E é claro que a perda de tempo de foco leva a novos erros e a um lento processo de desenvolvimento.

Pensamento final

É claro que existem várias razões pelas quais a Garantia de qualidade é importante do ponto de vista da reputação comercial, mas quero destacar as vantagens estratégicas de manter o controle de qualidade em uma equipe desde o início. Às vezes parece que algumas atividades de QA podem ser delegadas a outros membros da equipe, mas isso não é totalmente verdade. Isso é apenas uma falsa representação de uma responsabilidade bem distribuída, e um dia essa bomba-relógio se tornará uma ameaça ao desenvolvimento futuro do projeto.