important software test metrics
Em projetos de software, é mais importante medir a qualidade, o custo e a eficácia do projeto e dos processos. Sem medir isso, um projeto não pode ser concluído com sucesso.
No artigo de hoje, vamos aprender com exemplos e gráficos - Métricas e medições de teste de software e como usá-los no processo de teste de software.
Existe uma declaração famosa: “Não podemos controlar coisas que não podemos medir”.
Aqui, controlar os projetos significa como um gerente de projeto / líder pode identificar os desvios do plano de teste o mais rápido possível, a fim de reagir no tempo perfeito. A geração de métricas de teste com base nas necessidades do projeto é muito importante para atingir a qualidade do software que está sendo testado.
O que você aprenderá:
- O que são métricas de teste de software?
- O que é medição de teste de software?
- Por que testar métricas?
- Ciclo de vida de métricas
- Tipos de métricas de teste manual
- Exemplos de métricas de teste de software
- Conclusão
- Leitura recomendada
O que são métricas de teste de software?
Uma métrica é uma medida quantitativa do grau em que um sistema, componente do sistema ou processo possui um determinado atributo.
As métricas podem ser definidas como “PADRÕES DE MEDIÇÃO ”.
Métricas de software são usadas para medir a qualidade do projeto. Simplesmente, uma métrica é uma unidade usada para descrever um atributo. Metric é uma escala de medição.
Suponha, em geral, “Quilograma” é uma métrica para medir o atributo “Peso”. Da mesma forma, no software, “Quantos problemas são encontrados em mil linhas de código?”, H Além disso O número de problemas é uma medida e o número de linhas de código é outra medida. A métrica é definida a partir dessas duas medidas .
Exemplo de métricas de teste:
- Quantos defeitos existem no módulo?
- Quantos casos de teste são executados por pessoa?
- O que é% de cobertura do teste?
O que é medição de teste de software?
A medição é o indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo.
Exemplo de medição de teste: Número total de defeitos.
Consulte o diagrama abaixo para uma compreensão clara da diferença entre medição e métricas.
![]()
Por que testar métricas?
A geração de métricas de teste de software é a responsabilidade mais importante do líder / gerente de teste de software.
Test Metrics são usados para,
- Tome a decisão para a próxima fase de atividades, tais como, estimativa de custo e cronograma de projetos futuros.
- Entenda o tipo de melhoria necessária para o sucesso do projeto
- Tome uma decisão sobre o processo ou tecnologia a ser modificado, etc.
Importância das Métricas de Teste de Software:
Conforme explicado acima, Test Metrics são os mais importantes para medir a qualidade do software.
Agora, como podemos medir a qualidade do software usando Metrics ?
Suponha que, se um projeto não tiver nenhuma métrica, como a qualidade do trabalho realizado por um Analista de Teste será medida?
Por exemplo, Um analista de teste deve,
- Projete os casos de teste para 5 requisitos
- Execute os casos de teste projetados
- Registre os defeitos e a necessidade de falhar nos casos de teste relacionados
- Depois que o defeito for resolvido, precisamos testá-lo novamente e executar novamente o caso de teste com falha correspondente.
No cenário acima, se as métricas não forem seguidas, o trabalho concluído pelo analista de teste será subjetivo, ou seja, o Relatório de teste não terá as informações adequadas para saber o andamento de seu trabalho / projeto.
Se Metrics estiver envolvido no projeto, o status exato de seu trabalho com números / dados adequados pode ser publicado.
qual o melhor conversor de video
ou seja, no Relatório de Teste, podemos publicar:
- Quantos casos de teste foram projetados por requisito?
- Quantos casos de teste ainda precisam ser projetados?
- Quantos casos de teste são executados?
- Quantos casos de teste foram aprovados / reprovados / bloqueados?
- Quantos casos de teste ainda não foram executados?
- Quantos defeitos são identificados e qual é a gravidade desses defeitos?
- Quantos casos de teste falharam devido a um defeito específico? etc.
Com base nas necessidades do projeto, podemos ter mais métricas do que uma lista acima mencionada, para saber o status do projeto em detalhes.
Com base nas métricas acima, o Líder de Teste / Gerente entenderá os pontos-chave mencionados abaixo.
- % ge de trabalho concluído
- % ge de trabalho ainda a ser concluído
- Tempo para concluir o trabalho restante
- Se o projeto está indo de acordo com o cronograma ou atrasado? etc.
Com base nas métricas, se o projeto não for concluído de acordo com o cronograma, o gerente alertará o cliente e outras partes interessadas, fornecendo os motivos do atraso para evitar surpresas de última hora.
Ciclo de vida de métricas
![]()
Tipos de métricas de teste manual
As métricas de teste são divididas principalmente em 2 categorias.
- Métricas básicas
- Métricas Calculadas
Métricas básicas: Métricas básicas são as métricas derivadas dos dados coletados pelo Test Analyst durante o desenvolvimento e execução do caso de teste.
Esses dados serão rastreados durante todo o ciclo de vida do teste. Ou seja coletando os dados como Total no. de casos de teste desenvolvidos para um projeto (ou) não. de casos de teste precisam ser executados (ou) não. de casos de teste aprovados / reprovados / bloqueados etc.
Métricas calculadas: As métricas calculadas são derivadas dos dados coletados nas métricas básicas. Essas métricas geralmente são rastreadas pelo líder / gerente de teste para fins de relatório de teste.
Exemplos de métricas de teste de software
Vamos dar um exemplo para calcular várias métricas de teste usadas em relatórios de teste de software:
Abaixo está o formato de tabela para os dados recuperados do Test Analyst que está realmente envolvido no teste:
![]()
Definições e fórmulas para cálculo de métricas:
# 1)% ge casos de teste executados : Esta métrica é usada para obter o status de execução dos casos de teste em termos de% ge.
% ge Casos de teste executados = ( Nº de casos de teste executados / Nº total de casos de teste escritos) * 100.
Então, a partir dos dados acima,
% ge Casos de teste executados = (65/100) * 100 = 65%
# 2)% ge Casos de teste não executados : Esta métrica é usada para obter o status de execução pendente dos casos de teste em termos de% ge.
% ge Casos de teste não executados = ( Nº de casos de teste não executados / Nº total de casos de teste escritos) * 100.
Então, a partir dos dados acima,
% ge Casos de teste bloqueados = (35/100) * 100 = 35%
![]()
![]()
# 3)% ge casos de teste aprovados : Esta métrica é usada para obter a% ge de Aprovação dos casos de teste executados.
% ge casos de teste aprovados = ( Nº de casos de teste aprovados / Nº total de casos de teste executados) * 100.
Então, a partir dos dados acima,
% ge casos de teste aprovados = (30/65) * 100 = 46%
# 4)% ge casos de teste com falha : Esta métrica é usada para obter a% ge de falha dos casos de teste executados.
% ge casos de teste com falha = ( Nº de casos de teste com falha / Nº total de casos de teste executados) * 100.
Então, a partir dos dados acima,
% ge casos de teste aprovados = (26/65) * 100 = 40%
# 5)% ge casos de teste bloqueados : Esta métrica é usada para obter a% ge bloqueada dos casos de teste executados. Um relatório detalhado pode ser enviado especificando o motivo real do bloqueio dos casos de teste.
% ge casos de teste bloqueados = ( Nº de casos de teste bloqueados / Nº total de casos de teste executados) * 100.
Então, a partir dos dados acima,
% ge Casos de teste bloqueados = (9/65) * 100 = 14%
![]()
![]()
# 6) Densidade de defeito= Nº de defeitos identificados / tamanho
( Aqui, o “tamanho” é considerado um requisito. Portanto, aqui a densidade de defeito é calculada como um número de defeitos identificados por requisito. Da mesma forma, a densidade de defeitos pode ser calculada como um número de defeitos identificados por 100 linhas de código (OU) Nº de defeitos identificados por módulo, etc. )
Então, a partir dos dados acima,
Densidade de defeito = (30/5) = 6
# 7) Eficiência de Remoção de Defeito (DRE)= ( Nº de defeitos encontrados durante o teste de QA / (Nº de defeitos encontrados durante o teste de QA + Nº de defeitos encontrados pelo usuário final)) * 100
DRE é usado para identificar a eficácia do teste do sistema.
Suponha que, durante os testes de desenvolvimento e controle de qualidade, identificamos 100 defeitos.
Após o teste de QA, durante o teste Alfa e Beta, o usuário final / cliente identificou 40 defeitos, que poderiam ter sido identificados durante a fase de teste de QA.
Agora, o DRE será calculado como,
DRE = (100 / (100 + 40)) * 100 = (100/140) * 100 = 71%
# 8) Vazamento de defeito: Vazamento de defeito é a métrica que é usada para identificar o eficiência do teste de controle de qualidade ou seja, quantos defeitos foram perdidos / escorregados durante o teste de controle de qualidade.
Vazamento de defeito = ( Nº de defeitos encontrados no UAT / Nº de defeitos encontrados nos testes de controle de qualidade.) * 100
Suponha que, durante os testes de desenvolvimento e controle de qualidade, identificamos 100 defeitos.
Após o teste de QA, durante o teste Alfa e Beta, o usuário final / cliente identificou 40 defeitos, que poderiam ter sido identificados durante a fase de teste de QA.
Vazamento de defeito = (40/100) * 100 = 40%
# 9) Defeitos por prioridade : Esta métrica é usada para identificar o não. de defeitos identificados com base na Severidade / Prioridade do defeito que é usado para decidir a qualidade do software.
% ge Defeitos Críticos = Nº de Defeitos Críticos Identificados / Nº Total de defeitos identificados * 100
A partir dos dados disponíveis na tabela acima,
% ge Defeitos Críticos = 6/30 * 100 = 20%
% ge Defeitos elevados = Nº de defeitos elevados identificados / Nº total. de defeitos identificados * 100
A partir dos dados disponíveis na tabela acima,
% ge Defeitos elevados = 10/30 * 100 = 33,33%
% ge Defeitos médios = Nº de defeitos médios identificados / Nº total. de defeitos identificados * 100
A partir dos dados disponíveis na tabela acima,
% ge Defeitos médios = 6/30 * 100 = 20%
% ge Defeitos baixos = Nº de defeitos baixos identificados / Nº total. de defeitos identificados * 100
A partir dos dados disponíveis na tabela acima,
% ge defeitos baixos = 8/30 * 100 = 27%
![]()
Leitura recomendada=> Como escrever um relatório de resumo de teste eficaz
Conclusão
As métricas fornecidas neste artigo são usadas principalmente para gerar o Relatório de status diário / semanal com dados precisos durante a fase de desenvolvimento / execução do caso de teste e isso também é útil para rastrear o status do projeto e a qualidade do software.
Sobre o autor : Esta é uma postagem convidada por Anuradha K. Ela tem mais de 7 anos de experiência em testes de software e atualmente trabalha como consultora para uma MNC. Ela também tem bons conhecimentos em testes de automação móvel.
Quais outras métricas de teste você usa em seu projeto? Como de costume, deixe-nos saber sua opinião / dúvidas nos comentários abaixo.
Leitura recomendada
- Exercícios de teste de software - nova plataforma para testar suas habilidades de teste e compartilhar ideias práticas
- O que é Endurance Testing in Software Testing (exemplos)
- Como revisar o documento SRS e criar cenários de teste - Treinamento de teste de software em um projeto ativo - Dia 2
- Treinamento de teste de software: treinamento de ponta a ponta em um projeto ao vivo - treinamento de controle de qualidade online gratuito - parte 1
- Teste de aplicativos - Noções básicas de teste de software!
- QTP Tutorial # 18 - Estruturas baseadas em dados e híbridas explicadas com exemplos de QTP
- O que é o ciclo de vida do teste de software (STLC)?
- Metadados em Data Warehouse (ETL) explicados com exemplos