Menu

Guia completo sobre densidade de defeitos - sua importância e como calculá-la.

all one guide defect density its importance

Experimente Nosso Instrumento Para Eliminar Problemas

Um guia para detectar densidade:

Test Metrics são complicados. Eles são a única maneira de medir, mas a variedade é impressionante.

Você pode estar coletando algo que não está fornecendo as análises que deseja. A maneira mais segura aqui é caminhar por um caminho bem conhecido.

Quase todas as equipes no mundo confiam na Densidade de defeitos para entender as tendências dos defeitos.

O artigo de hoje é um guia completo sobre Densidade de Defeitos (DD).

Guia de densidade de defeito

criando um makefile c ++

O que você aprenderá:

O que é densidade de defeito?

Vejamos o que densidade significa literalmente.

É “o grau de compactação de uma substância (Fonte: Google)”.

Portanto, Densidade de Defeito é a compactação dos defeitos na aplicação. (Ok, então é apenas uma versão refinada de distribuição de defeitos.)

Os aplicativos são divididos em áreas funcionais ou mais tecnicamente QUADRA (Mil linhas de código). Por isso, o número médio de defeitos em uma seção ou por KLOC de um aplicativo de software é a densidade de bug.

Como a densidade do bug é calculada?

É uma matemática simples.

Passo 1: Recolher a matéria-prima: Você vai precisar do nº total. de defeitos (para um lançamento / construção / ciclo).

Passo 2: Calcule a média não. de defeitos / área funcional ou KLOC

Fórmula de densidade de defeito com exemplo de cálculo:

Exemplo 1: Para um determinado ciclo de teste, existem 30 defeitos em 5 módulos (ou componentes). A densidade seria:

Nº total de defeitos / Nº total de módulos = 30/5 = 6. DD por módulo é 6.

Exemplo # 2: Uma perspectiva diferente seria, digamos, há 30 defeitos para 15KLOC. Seria então:

Nº total de defeitos / KLOC = 30/15 = 0,5 = Densidade é 1 Defeito para cada 2 KLOC.

O exemplo 2 é apenas para aquelas equipes que conhecem o KLOC e precisam de uma medição em relação a ele. A maioria das equipes não trabalha com esse tipo de estatística. Mas se precisar, você pode descobrir quantos KLOC seu aplicativo tem.

Por que a densidade do bug é importante?

Cada métrica que a equipe de teste coleta transmite um dos seguintes:

  • Progresso
  • Produtividade
  • Qualidade

Se não, você está perdendo seu tempo.

DD é a maneira mais eficaz de entender a Qualidade.

Por exemplo: Uma aplicação com DD 5 por KLOC é de melhor qualidade em comparação com outra com 15 por KLOC.

Quanto maior a densidade do bug, pior é a qualidade.

Ele serve a dois propósitos importantes:

  • Informar: Informação é poder, não é? Conhecer as áreas mais fracas de seu aplicativo ajuda a decidir se ele é 'adequado para uso' ou não.
  • Frase de chamariz: Um módulo com maior DD precisa de conserto. DD ajuda a identificá-los.

Não é

# 1)Não leve em consideração duplicatas / defeitos devolvidos

A densidade de defeitos calculada incorretamente pode enganar sua equipe.

Não inclua duplicatas / defeitos retornados (não é um bug, funcionando como pretendido, não reproduzível , etc.) Aumenta a contagem do número total. de defeitos, o que significa que o DD aumentará proporcionalmente. Como resultado, sua métrica de defeito irá sugerir baixa qualidade, o que seria um alarme falso definitivo.

#dois)Não faça isso com base nos dados de um dia

Vejamos esta situação hipotética:

LO1

No dia 1, o DD é maior. Isso pode colocar sua equipe em pânico imediatamente.

Então, espere até ter melhor matéria-prima. Em outras palavras, alguns dias de dados.

Além disso, ao calcular DD, você deseja uma contagem cumulativa de defeitos.

Na tabela acima, seu DD do Dia 2 em diante não leva em consideração o número de defeitos até o momento. Ele analisa apenas os dados daquele dia sozinho.

Está me dando a impressão de que: “A densidade de defeitos desde o dia 2 está diminuindo e aumentando e não há tendência”. Além disso, como a densidade do defeito pode ser reduzida quando nada é feito sobre os defeitos relatados no dia anterior? Não é? Pense nisso.

A melhor maneira de fazer isso é:

LO2

Outra vez, se fizer isso diariamente, leve em consideração uma contagem cumulativa de defeitos.

Variações

Dependendo do nível de refinamento de que sua equipe precisa, você pode ajustar essa métrica de defeito.

Nº total de defeitos altos / críticos por KLOC ou módulos

  • Você também pode fazer isso para retornar problemas por módulos. Aqui, você coletará apenas a contagem de problemas que continuam voltando em compilações / lançamentos

Com quais valores de densidade de bug o software se torna inaceitável?

Padrão da indústria de densidade de defeito:

Bem, isso varia para cada setor, aplicativo e cada equipe. A fabricação teria um limite específico e seria completamente diferente para a TI.

DD em seu valor de face mostra baixa qualidade. Mas é, por sua vez, a gravidade dos defeitos individuais que decidem se o produto está apto para uso ou não.

High DD é o seu indicador para aprofundar e analisar seus defeitos e suas consequências.

Quem não gostaria de densidade de defeito zero, certo? Portanto, mesmo não havendo um padrão específico, quanto menor esse valor, melhor.

Pensamentos finais:

  • Não é uma contagem preditiva. Um valor de DD não ajuda a esperar a qualidade futura do produto. Pode ser melhor ou pior. Os dados históricos não ajudam nas previsões futuras.
  • Durante estágios / ciclos de teste críticos (como UAT), o DD é calculado com base no tempo.Por exemplo: DD / Primeira hora, DD por dia, etc.
  • Ao agrupar estatísticas de múltiplos defeitos de liberação / ciclo, a densidade do defeito pode ser por ciclo ou por liberação.
  • Uma representação gráfica simples dos dados tabulares pode ser a seguinte:

DD3

Gráfico de densidade de defeito

Para concluir

A densidade de defeitos é um indicador-chave de qualidade. Você não pode errar ao coletar e apresentar essa métrica de defeito. O que mais? É um dos mais fáceis de calcular.

Espero que este artigo tenha dado a você exposição suficiente para começar a usar Densidade de Defeito para insights mais profundos.

Autor : Swati, membro da equipe STH, escreveu este tutorial detalhado.

Você calcula a densidade de defeitos em suas equipes? Se sim, você faz isso por ciclo, por módulo ou por KLOC? Se não, que outras métricas o ajudam a entender a qualidade? Por favor, compartilhe seus comentários e perguntas abaixo.

Leitura recomendada

^