Guide tout-en-un sur la densité des défauts - son importance et comment la calculer.

all one guide defect density its importance

Un guide sur la densité des défauts:

Métriques de test sont délicats. Ils sont le seul moyen de mesurer, mais la variété est écrasante.

Vous pourriez collecter quelque chose qui ne vous donne pas les analyses que vous souhaitez. Le moyen le plus sûr ici est de marcher sur les sentiers bien battus.

Presque toutes les équipes dans le monde s'appuient sur la densité des défauts pour comprendre les tendances des défauts.

L'article d'aujourd'hui est un guide tout-en-un sur la densité des défauts (DD).

outil de réparation pc gratuit windows 10

Ce que vous apprendrez:

• Quelle est la densité des défauts?
• Comment la densité des bogues est-elle calculée?
• Pourquoi la densité des bogues est-elle importante?
• Pas
• Variations
• À quelles valeurs de densité de bogue le logiciel devient-il inacceptable?
• Dernières pensées:
• En conclusion
• lecture recommandée

Quelle est la densité des défauts?

Voyons ce que signifie littéralement la densité.

C'est «le degré de compacité d'une substance (Source: Google)».

Ainsi, la densité des défauts est la compacité des défauts dans l'application. (Ok, donc c'est juste une version raffinée de la distribution des défauts.)

Les applications sont divisées en domaines fonctionnels ou plus techniquement BLOQUER (Mille lignes de code). Donc, le nombre moyen de défauts dans une section ou par KLOC d'une application logicielle est la densité de bogues.

Comment la densité des bogues est-elle calculée?

C'est un simple calcul.

Étape 1: Récupérez la matière première: vous aurez besoin du total non. des défauts (pour une version / build / cycle).

Étape 2: Calculez le non moyen. des défauts / domaine fonctionnel ou KLOC

Formule de densité de défaut avec exemple de calcul:

Exemple 1: Pour un cycle de test particulier, il y a 30 défauts dans 5 modules (ou composants). La densité serait:

Total non. de défauts / Nb total de modules = 30/5 = 6. DD par module est de 6.

Exemple # 2: Une perspective différente serait, disons, qu'il y a 30 défauts pour 15KLOC. Ce serait alors:

Total non. de défauts / KLOC = 30/15 = 0,5 = La densité est de 1 défaut pour 2 KLOC.

L'exemple 2 est juste pour les équipes qui connaissent le KLOC et qui ont besoin d'une mesure par rapport à lui. La plupart des équipes ne travaillent pas avec ce type de statistique. Mais si vous en avez besoin, vous pouvez savoir combien de KLOC représente votre application.

Pourquoi la densité des bogues est-elle importante?

Chaque métrique collectée par l'équipe de test transmet l'un des éléments suivants:

• Le progrès
• Productivité
• Qualité

Sinon, vous perdez votre temps.

DD est le moyen le plus efficace de comprendre la qualité.

Par exemple: Une application avec DD 5 par KLOC est de meilleure qualité qu'une autre avec 15 par KLOC.

Plus la densité de bogues est élevée, plus la qualité est mauvaise.

Il sert deux objectifs importants:

• Informer: L’information, c’est le pouvoir, non? Connaître les points faibles de votre application permet de décider si elle est «adaptée à l’utilisation» ou non.
• Appel à l'action: Un module avec un DD plus élevé doit être réparé. DD aide à les identifier.

Pas

#1)Ne pas prendre en compte les doublons / défauts retournés

Une densité de défauts mal calculée peut induire votre équipe en erreur.

N'incluez pas les doublons / défauts retournés (pas un bogue, fonctionnant comme prévu, non reproduisible , etc.) Il augmente le décompte du total non. de défauts, ce qui signifie que le DD augmentera proportionnellement. En conséquence, votre métrique de défaut suggérera une qualité médiocre, ce qui serait une fausse alarme définitive.

#deux)Ne faites pas cela sur la base des données d'une journée

Regardons cette situation hypothétique:

Au jour 1, le DD est plus élevé. Cela pourrait envoyer votre équipe en mode panique immédiatement.

Alors, attendez d'avoir une meilleure matière première. En d’autres termes, quelques jours de données.

De plus, lors du calcul de DD, vous voulez un nombre cumulatif de défauts.

Dans le tableau ci-dessus, votre DD à partir du jour 2 ne prend pas en compte le nombre de défauts jusqu'à présent. Il examine uniquement les données de ce jour-là.

Cela me donne l'impression que: «La densité des défauts à partir du jour 2 diminue et augmente et il n'y a pas de tendance.» De plus, comment la densité des défauts peut-elle diminuer lorsque rien n'est fait sur les défauts signalés la veille? N'est-ce pas? Pensez-y.

Une meilleure façon de procéder est:

Encore une fois, si vous le faites quotidiennement, tenez compte d'un décompte cumulatif des défauts.

Variations

En fonction du niveau de raffinement dont votre équipe a besoin, vous pouvez modifier cette métrique de défaut.

• Pour DD de Problèmes de gravité élevée / critique , votre formule peut être:

Total non. de défauts élevés / critiques par KLOC ou modules

• Vous pouvez également le faire pour renvoyer des problèmes par module. Ici, vous ne collecterez que le nombre de problèmes qui reviennent sans cesse à travers les builds / versions

À quelles valeurs de densité de bogue le logiciel devient-il inacceptable?

Norme de l'industrie de densité de défaut:

Eh bien, cela varie pour chaque industrie, chaque application et chaque équipe. La fabrication aurait un seuil spécifique et ce serait complètement différent pour l'informatique.

DD à sa valeur nominale montre une qualité médiocre. Mais c'est, à son tour, la gravité des défauts individuels qui décide si le produit est apte à l'emploi ou non.

DD élevé est votre indicateur pour approfondir et analyser vos défauts pour leurs conséquences.

Qui n'aimerait pas une densité de défaut nulle, non? Par conséquent, même s'il n'y a pas de norme spécifique, plus cette valeur est basse, mieux c'est.

Dernières pensées:

• Ce n'est pas un décompte prédictif. Une valeur de DD ne permet pas d'attendre la qualité future du produit. Cela peut être meilleur ou pire. Les données historiques ne seront d'aucune utilité pour les prévisions futures.
• Pendant les étapes / cycles de test critiques (tels que UAT), DD est calculé en fonction du temps.Par exemple: JJ / Première heure, JJ par jour, etc.
• Lors de la compilation de statistiques de défauts de version / cycle multiples, la densité de défauts peut être par cycle ou par version.
• Une représentation graphique simple des données tabulaires peut être comme ci-dessous:

En conclusion

La densité des défauts est un indicateur de qualité clé. Vous ne pouvez pas vous tromper en collectant et en présentant cette statistique de défaut. Quoi de plus? C'est l'un des plus simples à calculer.

J'espère que cet article vous a donné suffisamment d'exposition pour commencer à utiliser la densité des défauts pour des informations plus approfondies.

Auteur : Swati, membre de l'équipe STH, a écrit ce tutoriel détaillé.

Calculez-vous la densité de défauts dans vos équipes? Si oui, le faites-vous par cycle, par module ou par KLOC? Sinon, quelles autres mesures vous aident à comprendre la qualité? Veuillez partager vos commentaires et questions ci-dessous.

lecture recommandée

• Qu'est-ce que la technique de test basée sur les défauts?
• Test alpha et test bêta (un guide complet)
• Meilleurs services de test de logiciels d'assurance qualité de SoftwareTestingHelp
• Types de tests logiciels: différents types de tests avec des détails
• Les tests logiciels sont une question d'idées (et comment les générer)
• Guide de CV de test logiciel parfait (avec exemple de CV de testeur de logiciel)
• Test fonctionnel vs test non fonctionnel
• Qu'est-ce que le cycle de vie des défauts / bogues dans les tests logiciels? Tutoriel sur le cycle de vie des défauts