Uma taxa de passagem de 95% pode significar que sua suite é eficaz ou que você removeu silenciosamente os testes difíceis que continuavam falhando. O número sozinho não diz nada sem saber o que você está medindo. A mesma ambiguidade se aplica à contagem de bugs por sprint e casos de teste escritos, que medem atividade, não qualidade.

Métricas que importam

Taxa de escape de defeitos

Definição: percentual de bugs que chegaram à produção versus bugs encontrados em testes. 

Taxa de Escape = (Bugs encontrados em produção / Total de bugs encontrados) × 100%

Exemplo: 20 bugs encontrados em testes + 5 bugs encontrados em produção = 25 no total. Taxa de escape = 5/25 = 20%. Por que importa: esta é a métrica mais próxima de "quão bem estamos encontrando bugs?" Uma taxa de escape alta significa que o QA não está capturando problemas antes que os usuários os encontrem. Meta: abaixo de 10% é razoável. Abaixo de 5% é forte.

Tempo Médio de Detecção (MTTD)

Definição: tempo médio desde que um bug é introduzido até ser reportado.

Um bug introduzido num commit na segunda-feira mas não encontrado até o ciclo de regressão de sexta tem um MTTD de 4 dias. Um bug encontrado por um teste automatizado 5 minutos após o commit tem MTTD de 5 minutos.

Por que importa: menor tempo de detecção significa correção mais barata. Um bug encontrado no CI custa 10x menos para corrigir do que um encontrado no QA, 100x menos do que um encontrado em produção. Como melhorar: shift left. Mais testes unitários, testes de integração automatizados e testes em cada commit empurram a detecção para mais cedo.

Taxa de automação de testes

Definição: percentual de casos de teste que estão automatizados. 

Taxa de Automação = (Testes automatizados / Total de casos de teste) × 100%

Por que importa: testes automatizados rodam em cada commit, encontram regressões imediatamente, e liberam o tempo de QA para testes exploratórios. Atenção: a taxa de automação bruta pode enganar. 90% de automação de testes triviais é pior do que 50% de automação dos fluxos de alto risco. Meça a automação dos caminhos críticos, não apenas todos os casos de teste.

Cobertura de testes

Três tipos valem rastrear. Cobertura de requisitos: qual % dos requisitos tem testes correspondentes. Cobertura de código: qual % do código é executado pelos testes (principalmente uma métrica de desenvolvimento, mas o QA deve entender). Cobertura de risco: as áreas de maior risco estão testadas? Lacunas de cobertura são onde bugs se escondem sem ser detectados. 100% de cobertura de requisitos não significa que casos extremos estão cobertos. Use junto com avaliação de risco.

Densidade de defeitos

Definição: número de bugs por unidade de tamanho de software. 

Densidade de Defeitos = Total de defeitos / Tamanho (kloc, story points, feature)

Compare a densidade de defeitos entre features, times ou sprints para identificar onde os problemas de qualidade estão concentrados. Se a feature X consistentemente tem 3x a densidade de defeitos de outras features, investigue o motivo: requisitos pouco claros, desenvolvimento apressado, código complexo?

Taxa de execução de testes

Definição: casos de teste planejados executados versus total planejado. 

Taxa de Execução = (Casos de teste executados / Casos de teste planejados) × 100%

Por que importa: taxa de execução baixa antes de um release é um sinal de risco. Você não concluiu os testes planejados.

Taxa de testes flaky

Definição: percentual de testes que às vezes passam e às vezes falham sem mudanças no código. 

Taxa de Flakiness = (Testes com resultados intermitentes / Total de testes) × 100%

Por que importa: testes flaky destroem a confiança do time na suite de testes. Quando o CI falha, ninguém sabe se é um bug real ou um teste flaky. Os times começam a ignorar as falhas. Então os bugs reais também são ignorados. Meta: abaixo de 2%. Se estiver maior, é prioridade corrigir.

Métricas que parecem boas mas enganam

Contagem de bugs por sprint

A armadilha: mais bugs encontrados não significa que o QA está trabalhando mais. A contagem de bugs depende de quantas features foram desenvolvidas, quão complexas eram, e quanto risco foi assumido. Um sprint com correções simples sempre terá menos bugs do que um com features novas e complexas. Melhor: rastreie contagem de bugs junto com velocidade de desenvolvimento e avaliação de risco.

Casos de teste escritos

A armadilha: escrever 100 casos de teste por sprint não é inerentemente melhor do que escrever 50. 100 casos de teste óbvios que testam o que obviamente funciona acrescenta menos valor do que 50 casos extremos cuidadosamente escolhidos que realmente encontram bugs. Melhor: rastreie cobertura de casos de teste dos requisitos, não a contagem bruta.

Taxa de passagem

A armadilha: "95% dos testes passam" soa ótimo. Mas pode significar que seus testes são trivialmente fáceis de passar, você removeu testes difíceis que continuavam falhando, ou falhas conhecidas estão sendo ignoradas. Melhor: rastreie a tendência da taxa de passagem ao longo do tempo e investigue por que testes falhando existem.

Rastreando métricas ao longo do tempo

Métricas só se tornam úteis quando rastreadas ao longo do tempo. Um snapshot único não diz nada. Tendências mostram se as coisas estão melhorando ou piorando.

Boas ferramentas: dashboards do Jira para métricas de defeitos, TestRail para rastreamento de execução de casos de teste, GitHub Actions ou Jenkins para métricas de automação, Grafana para dashboards customizados de dados de CI.

Abordagem simples, rastreamento semanal numa planilha:

| Semana | Bugs Encontrados | Bugs Escapados | Taxa de Automação | Taxa de Flakiness |

|--------|----------------|---------------|-------------------|-------------------|

| S1 | 15 | 2 | 60% | 8% |

| S2 | 12 | 1 | 63% | 6% |

| S3 | 18 | 0 | 65% | 5% |

| S4 | 10 | 2 | 68% | 4% |

Tendências: automação aumentando, taxa de flakiness diminuindo, taxa de escape baixa.

Reportando métricas para stakeholders

Time técnico (retrospectiva do sprint): contagem e tendência de testes flaky, progresso da taxa de automação, melhoria de MTTD com adições de testes. Gestão (mensal): taxa de escape de defeitos, bugs P1/P2 em produção versus período anterior, cobertura de testes de features críticas, tempo economizado pela automação versus testes manuais. Stakeholders não técnicos (trimestral): traduza números para impacto no negócio. "Prevenimos X problemas visíveis ao cliente este trimestre." "Nossa suite automatizada roda em 15 minutos, capturando regressões antes de chegar ao usuário." "A taxa de escape de defeitos caiu de 25% para 8% ano a ano."

Começando um programa de métricas

Não tente rastrear tudo de uma vez. Comece com dois ou três.

Mês 1: rastreie taxa de escape de defeitos e taxa de testes flaky. Estabeleça a linha de base. Meses 2 a 3: adicione taxa de automação de testes. Comece a mirar redução de testes flaky. Mês 4+: adicione MTTD e cobertura de requisitos. Revise tendências e defina metas de melhoria.

O objetivo é melhoria, não perfeição. Métricas que expõem problemas estão fazendo seu trabalho.

Resumo

| Métrica | O que mede | Por que importa |

|---------|-----------|----------------|

| Taxa de escape de defeitos | Bugs chegando à produção | Eficácia central de qualidade |

| MTTD | Velocidade de detecção de bugs | Custo de correção de bugs |

| Taxa de automação | Maturidade da suite de testes | Velocidade e cobertura de regressão |

| Taxa de flakiness | Confiabilidade dos testes | Confiabilidade da suite |

| Densidade de defeitos | Concentração de bugs | Onde focar esforço de qualidade |

| Cobertura de testes | Requisitos testados | Identificação de lacunas |

Boas métricas respondem: "Estamos melhorando?" Se suas métricas não mostram melhoria ao longo do tempo, são as métricas erradas ou você tem problemas de processo para resolver.

→ Veja também: Métricas QA que Realmente Importam: Taxa de Escape de Defeitos, MTTD e Mais | Relatórios de Testes no CI: Formatos, Ferramentas e Integração | Tornando-se QA Lead: Responsabilidades, Habilidades e a Transição