Não é novidade para ninguém que estamos passando por uma transformação na área de desenvolvimento de software, em que a IA está assumindo diversas atividades. E isso me faz pensar: o que vamos medir, ou o que teremos como parâmetro para qualidade de software daqui pra frente? É sobre isso que vou falar neste texto.
Antes das métricas: entenda o momento do seu time
Antes de entrarmos nas métricas em si, precisamos entender o momento em que o nosso time está. É muito fácil eu simplesmente jogar métricas aqui e você aplicá-las ao seu time de maneira automática — mas será que elas fazem sentido para o seu contexto?
Uma coisa que eu falo bastante aos meus alunos da mentoria que dou na He4rt Developers é: pra que eu quero isso? Softwares representam necessidades do mundo real, logo, medir o sucesso e a qualidade deles vai depender muito das necessidades que eles buscam suprir.
Partindo agora para as métricas, eu gosto de dividi-las em dois grupos:
- Métricas para stakeholders
- Métricas para o time
Qualidade de software não se resume a número de bugs — ela se aplica tanto em como o software é recebido pelo cliente final, quanto em como ele é desenvolvido.
Métricas para stakeholders
Uma coisa que eu aprendi neste tempo na empresa em que tenho atuado, principalmente com a transformação digital, é que mostrar número de bugs abertos ou resolvidos não mostra para o público o que realmente importa: como está a qualidade do produto. E, para me ajudar nisso, eu sempre tento me colocar no lugar de um cliente que não tem conhecimento profundo sobre o ciclo de desenvolvimento de software.
A primeira coisa que eu gostaria de ver quando um QA, ou o time, vier me mostrar os resultados de uma sprint ou de um quarter é: quantos problemas eu tenho em produção — mas não só isso, quanto tempo tenho levado para resolvê-los.
Mean Time to Resolve/Repair (MTTR)
Essa é a famosa métrica que vai mostrar o tempo que leva desde que o problema é identificado até ele ser resolvido em produção. Dependendo de como é o seu processo de desenvolvimento, isso pode ser medido de formas diferentes. Se você tem um processo em que o cliente primeiro reporta para o suporte, o suporte faz uma pré-avaliação e só depois disso o problema vai para o time resolver, você pode medir em dois momentos: o tempo que o suporte leva para avaliar o problema e dar um primeiro parecer, e o tempo em que esse ticket de suporte de fato se torna um bug e entra na esteira de resolução.
Cobertura de testes automatizados
Outra métrica interessante de se mostrar para um time de stakeholders é a quantidade de testes automatizados — porém, não isolada. Acho que você já deve estar cansado de ouvir que ter 99% de cobertura de testes não significa qualidade, mas como posso apresentar essa métrica ao stakeholder de forma que ele veja o valor do investimento em automação que o seu time está fazendo?
Uma coisa importante a analisar nesse contexto é se a cobertura de testes está realmente pegando os cenários importantes do sistema. Exemplo: se, no seu contexto, o seu MTTR está alto mas a sua cobertura de testes está alta, isso significa que a sua cobertura não está cobrindo o que realmente precisa ser coberto.
DORA Metrics
Além dessas, as DORA Metrics são grandes aliadas para auxiliar nesse diagnóstico.
As DORA Metrics (DevOps Research and Assessment, hoje parte do Google Cloud) nasceram para medir a performance de entrega de software, mas, na prática, funcionam como um termômetro da qualidade do processo como um todo — porque times que entregam rápido e com poucos incidentes são times com um pipeline de qualidade (testes, revisão, observabilidade) bem construído.
Fonte oficial: dora.dev — pesquisa contínua do DORA (Google Cloud) sobre as métricas e capacidades que diferenciam times de alta performance. Vale a leitura direta da fonte para acompanhar atualizações do modelo, como a inclusão de Reliability como quinta métrica.
Deployment Frequency (Frequência de Deploy)
Com que frequência o time coloca código em produção. Deploys menores e mais frequentes são mais fáceis de testar e, se algo der errado, mais fáceis de isolar a causa — menos mudanças acumuladas por deploy significa menos variáveis para investigar. Uma frequência de deploy caindo pode ser sintoma de um time com medo de quebrar produção, geralmente por falta de confiança nos testes.
Lead Time for Changes (Tempo entre o commit e a produção)
Tempo desde que uma mudança é commitada até ela estar rodando em produção. Um lead time alto muitas vezes esconde um gargalo em etapas de validação manual demoradas, ou retrabalho por bugs encontrados tarde no ciclo. É uma métrica que expõe se o teste está acontecendo cedo (shift-left) ou só no fim, represando a entrega.
Change Failure Rate (Taxa de Falha em Mudanças)
Percentual de deploys que causam falha em produção (incidente, rollback, hotfix). É, de longe, a métrica DORA mais diretamente ligada à qualidade do processo de teste. Está diretamente relacionada à cobertura de testes: se essa métrica está alta, significa que a sua cobertura de testes está baixa ou, como dito anteriormente, não está cobrindo o que realmente precisa ser coberto.
Time to Restore Service (Tempo de Restauração)
Tempo médio para restaurar o serviço depois de um incidente em produção (rollback, hotfix, correção de configuração). Mede a capacidade do time de reagir quando — não se — algo dá errado. QA pode influenciar diretamente essa métrica ajudando a desenhar testes de rollback, feature flags e smoke tests pós-deploy que aceleram a detecção e a decisão de reverter.
Reliability (Confiabilidade — métrica mais recente do modelo DORA)
O quanto o sistema atende às expectativas de disponibilidade e performance do usuário no dia a dia, não só durante incidentes. Conecta a qualidade percebida pelo usuário com o trabalho de teste não funcional (performance, disponibilidade) — é o lembrete de que qualidade não é só "não ter bug", é o sistema se comportar bem sob uso real.
Métricas para o time
As métricas para stakeholders ajudam bastante o time a ver o estado daquilo que estão produzindo, mas, às vezes, você quer enxergar a qualidade no próprio processo de desenvolvimento do software. Aqui podemos ter métricas mais pontuais.
Root Cause Analysis
São métricas que ajudam a ver os padrões dos problemas que acontecem no software ou durante o desenvolvimento e, a partir delas, pensar em planos de ação. Exemplo: se eu tenho muitos problemas relacionados a falta de requisitos, posso deixar os requisitos mais explícitos nas tarefas e, daqui a 2 ou 3 sprints, validar se esse tipo de root cause se tornou menos frequente ou não.
Bugs identificados antes do lançamento
Existem algumas métricas que você também pode extrair relacionadas a bugs, como: quantos bugs foram identificados antes mesmo de lançarmos a feature em produção? Isso pode ser alimentado tanto pela execução de testes manuais quanto por testes automatizados que falharam ao adicionar uma nova feature.
Retrabalho
É possível também calcular o retrabalho, uma métrica que vai te ajudar tanto a ver se o número de bugs está aumentando ou não quanto no planejamento. Quando o seu time costuma ter uma taxa de retrabalho de 10%, é possível alinhar com os Product Owners 10% de margem dentro de uma sprint para possíveis bugs. Assim, o planejamento se torna mais realista, as expectativas ficam alinhadas, e o cliente e o time ficam mais felizes.
Conclusão
Com essa transformação digital, é importante entendermos que temos métricas que podem nos auxiliar a medir o ciclo de desenvolvimento e a qualidade do produto — e o principal é que nenhuma delas, isoladamente, traz valor. Elas precisam ser lidas em conjunto, cruzadas entre si, e sempre voltando para aquela pergunta inicial: pra que eu quero isso?
Com a IA aumentando a produção de código, a tendência é termos mais código sendo escrito, mais features sendo entregues e mais decisões sendo tomadas em menos tempo. E é justamente por isso que medir vai se tornar ainda mais importante do que já é hoje: se antes um time levava dias para gerar uma quantidade de código que hoje pode ser gerada em horas, os erros também podem se multiplicar na mesma velocidade — só que muitas vezes invisíveis até chegarem em produção.
Por isso, acho que o papel do QA nesse novo cenário não é só testar mais rápido para acompanhar o ritmo da IA, mas também ser a pessoa que garante que estamos olhando para os números certos. Não adianta ganhar velocidade e perder visibilidade sobre o que está sendo entregue. Então, o convite que eu deixo é: olhe para essas métricas não como números para preencher um dashboard, mas como perguntas que elas estão te fazendo sobre o seu processo. E use a IA para te ajudar a responder essas perguntas mais rápido — não para substituir o hábito de perguntar.
Top comments (0)