A taxa de escape de defeitos diz qual percentual de bugs chegou aos usuários em vez de ser capturado no QA. Ela é o número único mais próximo de "quão bem o QA está funcionando". A porcentagem de cobertura de testes é fácil de inflar para 95% escrevendo asserções que nunca verificam nada de verdade.
Métricas que importam
Taxa de escape de defeitos
O que é: o percentual de bugs encontrados pelos clientes (em produção) versus encontrados durante o QA. Fórmula:Bugs encontrados em produção / Total de bugs encontrados × 100
Por que importa: esta é a medida mais direta de eficácia do QA. Se você está encontrando 90% dos bugs antes do release, sua taxa de escape é 10%. Se os clientes estão encontrando metade dos bugs, algo está errado com a cobertura.
Meta: varia pelo risco do produto. Sistemas de pagamento devem mirar menos de 2%. Ferramentas internas toleram taxas maiores.
Antipadrão: um time com zero bugs em produção não está necessariamente fazendo ótimo QA: pode estar lançando muito devagar, ou o produto é usado tão raramente que bugs não são reportados.
Densidade de defeitos
O que é: bugs por unidade de código ou feature. Fórmula:Bugs encontrados / Linhas de código (ou story points, ou features) para um release
Por que importa: rastreia onde os bugs se concentram. Um módulo com 10x a densidade de defeitos do restante do código precisa de atenção: mais cobertura de testes, revisão de código, ou refatoração.
Como usar: identificar áreas de alto risco para priorizar na regressão. Justificar investimento em cobertura de testes para módulos específicos.
Taxa de passagem ao longo do tempo
O que é: percentual de testes passando no CI ao longo do tempo, rastreado por execução. Por que importa: uma taxa de passagem gradualmente em declínio é um alerta antecipado. O produto está acumulando regressões, ou a suite está acumulando flakiness. Os dois precisam de atenção. Sinal de alerta: uma taxa de passagem estável em 85% significa que 15% dos testes sempre falham, o que significa que o time normalizou a falha. A suite parou de ser um sinal confiável.Tempo médio de detecção (MTTD)
O que é: tempo médio entre quando um bug é introduzido e quando é detectado. Por que importa: se bugs levam 2 semanas para ser detectados, geralmente são encontrados depois que o autor da correção já seguiu em frente. O contexto se perdeu e a correção é mais cara. MTTD curto significa loops de feedback rápidos. Como reduzir: shift left. Testes unitários rodam em segundos, testes de integração em minutos, E2E no CI em cada PR. Quanto mais cedo no pipeline os bugs são capturados, menor o MTTD.Tendência do tempo de execução dos testes
O que é: quanto tempo sua suite de testes leva para rodar, rastreado ao longo do tempo. Por que importa: uma suite que leva 45 minutos para rodar não é executada em cada commit. Os desenvolvedores começam a pular. O loop de feedback quebra. Tendência saudável: o tempo de execução deve crescer lentamente em relação à contagem de features. Se adicionar 10 features dobra o tempo da suite, a arquitetura de testes tem um problema de paralelização.Métricas que parecem úteis mas não são
Porcentagem de cobertura de testes
Cobertura é a métrica de QA mais rastreada e menos útil. Um número de 95% de cobertura de linhas diz quais linhas foram executadas pelos testes; não diz nada sobre se essas linhas foram verificadas corretamente.
Times jogam o jogo constantemente: escrevem testes que executam código sem fazer asserções com significado, e a cobertura sobe enquanto a qualidade real não vai a lugar nenhum. Use cobertura como um piso ("não faremos merge de código abaixo de 80% de cobertura"), não como sinal de qualidade.
Número de casos de teste
"Temos 10.000 casos de teste" não tem significado sem saber quantos estão automatizados, quantos realmente rodam, e quantos estão atualizados. Uma suite com 500 testes bem mantidos, rápidos e confiáveis vale mais do que 10.000 casos de teste manuais desatualizados que ninguém roda.
Bugs fechados por sprint
Fechar bugs não é o objetivo: preveni-los é. Um time fechando 50 bugs por sprint pode estar numa posição péssima (bugs escapando rápido o suficiente para gerar trabalho constante) ou numa posição boa (trabalhando em dívida técnica antiga). O número sozinho não diz nada.
Métricas de QA que ajudam na comunicação com stakeholders
Quando stakeholders não técnicos perguntam sobre QA, geralmente querem entender risco, não metodologia. Enquadre as métricas de acordo:
Enquadramento orientado a risco:- "Temos 3 bugs de alta severidade abertos contra o fluxo de pagamento. Recomendamos atrasar o release mobile até que 2 sejam resolvidos."
- "A taxa de escape de defeitos aumentou de 8% para 14% neste trimestre: estamos encontrando mais bugs após o release. A causa raiz é cobertura de regressão reduzida na camada de API."
- "A suite de testes E2E passou de 22 minutos para 9 minutos após paralelização. O feedback de CI em PRs agora é menor que 10 minutos."
- "A taxa de testes flaky caiu de 15% para 3% neste trimestre após correções de isolamento."
Essas são conversas, não dashboards. As métricas existem para servir decisões: staffing, timing de release, investimento técnico, não para existir por conta própria.
Como começar a rastrear
Você não precisa de uma ferramenta especializada de métricas de QA para começar. Uma planilha com quatro colunas funciona:
| Semana | Bugs encontrados no QA | Bugs encontrados em prod | Tempo de execução da suite |
|--------|----------------------|--------------------------|---------------------------|
| 2026-S20 | 18 | 3 | 34 min |
| 2026-S21 | 22 | 1 | 34 min |
| 2026-S22 | 15 | 5 | 37 min |
Tendências são mais acionáveis do que pontos de dados únicos. Após quatro semanas, você vai ver se os escapes para produção estão aumentando ou diminuindo, e se sua suite está ficando mais lenta.
→ Veja também: Métricas e KPIs de QA: O que Medir e Por quê | Relatórios de Testes no CI: Formatos, Ferramentas e Integração | Tornando-se QA Lead: Responsabilidades, Habilidades e a Transição
