Antes do QA, Antes do Deploy: Testou na Sua Máquina?

Eu sou do tempo em que o desenvolvedor testava

Taking a Step Back

Vamos dar um passo para trás, esquecendo, por um momento, de sensores e alarmes do pipe, de automações complexas, e, até mesmo, de checklists de aprovação de PRs. Vamos voltar mais um pouco, antes de deploys e merges, para a máquina do desenvolvedor, onde ele acaba de "concluir" uma tarefa.

O desenvolvedor concluiu mesmo a tarefa? Ele apenas se certificou de que não há erros/warnings no seu IDE e/ou de que o código compilou, ou ele se deu ao trabalho de testar minimamente aquilo que ele acabou de desenvolver? Não estou falando aqui de teste unitário "codado", mas do bom e velho teste local. O desenvolvedor olhou a aplicação, por alguns minutos que seja, certificando-se de que sua atualização realmente funciona para o usuário?

Gastando à Toa

O custo da Qualidade é minimizado quando a falha é detectada na mesma fase de desenvolvimento em que ela foi introduzida, e este custo fica menor ainda se esta é a fase"inicial": o teste local do desenvolvedor.

Encontrar um bug nesta fase é encontrar o bug mais "barato" que pode haver. Não há burocracias, report de defeitos, cards voltando, teste e reteste de QA. É so notar que o erro está lá, e corrigir.

Desenhando, vejamos. Considere um código recém desenvolvido, ainda em fase de teste local, e que contém um erro. Vamos considerar duas situações, uma (situação 1) em que o desenvolvedor testa localmente, e outra (situação 2), em que o desenvolvedor não testa localmente. Vamos considerar, ainda, que se trata de um bug funcional.

Na situação 1, o desenvolvedor encontra o bug imediatamente e o corrige. O custo do bug é:

custo = tempo de desenvolvimento + tempo de teste local + tempo de correção + tempo do segundo teste local

Na situação 2, o bug é encontrado na fase de QA (poderia ser pior, poderia escapar para homologação ou produção, mas sejamos conservadores). Neste caso, o custo do bug fica:

custo = tempo de desenvolvimento + tempo de deploy + tempo de teste de QA + tempo de reporte do bug + tempo de priorização do bug + tempo de troubleshooting + tempo de correção do bug + tempo de teste local (considerando que o desenvolvedor "aprendeu a lição") + tempo de deploy + tempo de reteste do QA (teste de confirmação) + tempo de atualização do registro do bug

Não restam duvidas de qual situação custa mais para o projeto, certo? Sem contar o fato de que, na situação 2, o tempo extra perdido pode comprometer a realização de outras tarefas planejadas, potencializando o impacto. Não investir em teste local, claramente, é esbanjar recursos do projeto.

Soluções Simples

A situação 2, infelizmente, é muito comum. A análise de causas-raiz de bugs em centenas de projetos que acompanhei e/ou acompanho me traz o dado empírico de que, em alguns casos, até 60% dos bugs encontrados poderiam ter sido detectados em simples e rápidos testes locais. Além disso, estudos mostram que testes tradicionais cobrem apenas cerca de 35% dos defeitos, enquanto que testes locais feitos por desenvolvedores capturam de 50 a 65%  dos bugs.

Considerando este cenário, tenho implementado modelos de Qualidade em que existe a garantia do teste local do desenvolvedor. A implementação desta garantia pode ser mais simples ou mais complexa, a depender do contexto do projeto, mas sempre se mostra muito eficaz em reduzir custos e retrabalhos.

Com o advento da IA como ferramenta em Qualidade de Software, verificações semânticas podem também melhorar a eficácia de testes unitários, minimizando o impacto da falta de teste local. Mas daí sempre temos o perigo de apenas "mudar o problema de lugar", pois a própria chamada de verificação semântica pode, ela mesma, conter falhas funcionais. Além disso, um efeito observado na prática é o time acreditar que, por ter uma camada extra de verificação (seja linting, seja IA), não precisa mais fazer o básico: rodar a aplicação manualmente, clicar nos botões, ver o fluxo real do usuário.

Eu sou do tempo em que desenvolvedor testava. Mas, enfim, olhemos pelo lado positivo: naquele tempo, eu não teria material para escrever este artigo!