Guide du débutant sur les défauts dans les tests de logiciels

30 octobre 2021

Dans un monde parfait, le développement logiciel pourrait se dérouler sans heurts, et les phases de test et de vérification seraient rapides, avec presque aucun défaut à trouver.

Mais comme il ne s'agit que d'une imagination, les testeurs du monde réel doivent faire face aux anomalies et aux dysfonctionnements de chaque application logicielle.

La qualité du logiciel est déterminée par la propreté ou l'absence de bogue du logiciel ?



Ainsi, il est essentiel que les testeurs examinent les applications multicouches complexes et identifient, documentent, suivent et corrigent les nombreux bogues ou défauts.

Table des matières

Que signifie défaut ?

Un défaut est une condition qui se produit dans un produit logiciel lorsqu'il ne répond pas aux exigences ou aux attentes du logiciel.

Il peut s'agir d'une erreur dans le codage ou la logique du programme qui provoque son dysfonctionnement.

Ils sont définis comme des irrégularités ou des écarts par rapport aux résultats attendus résultant d'erreurs dans la phase de développement par un développeur.

Les défauts ou les bogues ou les défauts sont des lacunes ou des imperfections qui empêchent l'application logicielle d'exécuter ce qu'elle est censée faire.

Les défauts entraînent la défaillance d'une application logicielle.

Voici quelques-unes des méthodes adoptées pour empêcher l'introduction de bogues par les programmeurs au cours du développement :

  • Examen par les pairs
  • Analyse de codes
  • Techniques de programmation adoptées
  • Méthodologies de développement logiciel

Classification

Les classifications des défauts données ci-dessous ne sont que des lignes directrices. La base de classification des défauts dépend de l'organisation et de l'outil de suivi des défauts qu'elle utilise.

Les membres de l'équipe doivent avoir un accord préalable sur la classification des défauts à utiliser pour éviter de futurs conflits.

Les défauts peuvent être classés en fonction de :

Gravité

La gravité d'un défaut dépend de la complexité du défaut à corriger du point de vue du développement.

L'état de gravité a donné au testeur une idée de l'écart entre le logiciel et les spécifications.

Ça peut être:

  • Critique - Ces défauts reflètent des écarts de fonctionnalité cruciaux dans l'application logicielle sans correction qu'un testeur QA ne peut pas valider.
  • Majeur – Ces défauts sont détectés lorsqu'un module crucial de l'application fonctionne mal, mais que le reste du système fonctionne correctement. L'équipe d'assurance qualité doit résoudre ces problèmes, mais elle peut également valider le reste de l'application, que le défaut majeur soit corrigé ou non.
  • Moyen – Ces défauts sont liés à des problèmes dans un seul écran ou une seule fonction, mais ils n'affectent pas le fonctionnement du système dans son ensemble. Les défauts ne bloquent aucune fonctionnalité.
  • Faible - Ces défauts n'ont aucun impact sur la fonctionnalité de l'application logicielle. Cela peut être lié à une incohérence de l'interface utilisateur, à des défauts esthétiques ou à des suggestions pour améliorer l'expérience utilisateur de l'interface utilisateur.

Probabilité

La probabilité d'un défaut peut être définie comme la probabilité d'un défaut dans une caractéristique du système.

La probabilité de trouver un bogue dépend de l'utilisation de cette fonctionnalité particulière. Si l'attribut est rarement utilisé, le défaut trouvé aura de fortes chances. Néanmoins, si l'attribut est largement utilisé, le défaut peut avoir une faible probabilité, en fonction de la rareté de la découverte du défaut.

Ça peut être:

  • Élevé – Si un défaut est facilement trouvé par tous ou la plupart des utilisateurs de fonctionnalités, alors le défaut a une probabilité élevée.
  • Moyen – Si un défaut est détecté par au moins 50 % des utilisateurs de fonctionnalités, alors le défaut a une probabilité moyenne d'occurrence.
  • Faible – Si très peu d'utilisateurs de la fonctionnalité rencontrent un défaut, alors le défaut a une faible probabilité.

Priorité

L'importance ou l'urgence de réparer un particulier définit la priorité du défaut.

La priorité d'un défaut est définie par un testeur de logiciel et finalisé par le chef de projet.

Il peut être classé comme :

  • Urgent - Une résolution immédiate de cette catégorie de défauts est requise car ces défauts peuvent gravement affecter l'application et entraîner des réparations coûteuses s'ils ne sont pas traités.
  • Élevé – La résolution immédiate de ces défauts est essentielle car ces défauts affectent les modules d'application qui sont rendus inutiles jusqu'à ce que les défauts soient corrigés.
  • Moyen – Ce ne sont pas des défauts essentiels et peuvent être programmés pour être corrigés dans des versions ultérieures.
  • Faible - Une fois les défauts critiques ci-dessus corrigés, le testeur peut ou non les corriger.

Phase injectée

La phase du cycle de vie du développement logiciel dans laquelle le défaut a été introduit ou injecté pour la première fois peut également être utilisée pour classer les défauts.

La phase injectée d'un défaut est trouvée après une analyse appropriée des causes profondes.

Le défaut peut être injecté dans l'une des phases suivantes :

  • Développement des exigences
  • Conception détaillée
  • Conception de haut niveau
  • Codage
  • Déploiement

Phase détectée

Après la Phase injectée vient la Phase détectée. La Phase dans laquelle le défaut particulier a été identifié est appelée Phase détectée.

Il y a les phases suivantes dans Test de logiciel :

Module connexe

Le module dans lequel le défaut particulier a été détecté peut être utilisé comme classification du défaut.

La classification des modules associés fournit des informations sur le module contenant le plus de bogues.

Dimension connexe de la qualité

Il s'agit de centaines de dimensions de qualité logicielle telles que l'accessibilité, la compatibilité, la simultanéité et bien d'autres.

La décision quant à quelle dimension est la plus importante et doit être fixée en premier est subjective. Cela dépend uniquement de la dimension de plusieurs valeurs par le testeur dans cette situation particulière.

Exigences et défaut de spécification

L'écart client ou producteur (testeur ou développeur) peut entraîner des défauts liés aux exigences dans lesquels le développeur ou le testeur ne comprend pas les exigences du client.

Les documents d'exigences doivent être rédigés dans des exigences non ambiguës, non contradictoires, claires, non redondantes et précises pour réduire ces défauts.

Défauts de conception

Les interactions entre composants et modules incompatibles ou mal conçus entraînent des défauts dans le système.

Les algorithmes, les éléments logiques ou de données, les descriptions d'interface de module, les algorithmes et les descriptions d'interface utilisateur de logiciel ou de matériel externe doivent être correctement conçus pour éviter les défauts de conception.

Défauts de codage

De mauvaises implémentations de conceptions ou de codes en raison de l'absence de normes de développement ou de codage peuvent entraîner des défauts de codage.

Ces défauts sont étroitement liés aux défauts de conception des classes, principalement si les pseudo-classes sont utilisées dans la conception détaillée.

Parfois, il peut être difficile de classer un défaut comme un défaut de codage ou de conception.

Tester les défauts

Des tests erronés ou des défauts dans les artefacts de test entraînent des défauts de test.

Celles-ci peuvent être de trois types :

  • Défaut de l'outil de test - Les outils de test utilisés par les testeurs sont également capables d'introduire des défauts dans le logiciel. UNE essai manuel seront utilisés pour trouver les défauts causés par des outils automatisés.
  • Défaut de conception de test - Les défauts dans les artefacts de test tels que les plans de test, les scénarios de test, la définition des données de test et les cas de test sont appelés défauts de conception de test.
  • Défaut de l'environnement de test - Lorsque l'environnement de test, c'est-à-dire le matériel, les logiciels, les personnes chargées des tests et le simulateur, n'est pas défini, des défauts de l'environnement de test surviennent.

Statut

Un défaut peut être classé en fonction du statut ou de l'état du cycle de vie du défaut dans lequel se trouve actuellement le défaut.

Ces états peuvent être :

  • Ouvert
  • Fermé
  • Différé
  • Annulé

Produit Word

Sur la base du produit du travail ou des documents ou produits finaux d'une phase de développement, un défaut peut être classé comme :

  • Code source - Un défaut trouvé dans le code source de l'application.
  • SSD - Un défaut trouvé dans le document d'étude du système du logiciel.
  • Documentation utilisateur - Un défaut trouvé dans les manuels d'utilisation ou les manuels d'utilisation du logiciel.
  • ADS - Un défaut trouvé dans le document de conception architecturale du logiciel.
  • Plan de test ou cas de test - Un défaut trouvé dans le plan de test ou les cas de test du logiciel.
  • FSD - Un défaut trouvé dans le document de spécification fonctionnelle du logiciel.
  • DDS - Un défaut trouvé dans le document de conception détaillée du logiciel.

Les types

Voici quelques-uns des principaux types de défauts dans le développement de logiciels :

Types de défauts

Défauts logiques

Lors de l'implémentation du code, un programmeur peut ne pas comprendre clairement le problème ou penser de manière erronée. Dans de tels cas, des défauts logiques se produisent.

Les défauts logiques sont liés au cœur du logiciel et peuvent survenir si le programmeur n'implémente pas correctement les cas particuliers.

Défauts de performances

Lorsqu'un système ou l'application logicielle ne parvient pas à fournir les résultats souhaités et attendus et n'est pas en mesure de répondre aux exigences de l'utilisateur, des défauts de performance se produisent.

Ces défauts comprennent également la réponse du système à la variation de la charge du système.

Défauts de multithreading

L'exécution simultanée de plusieurs tâches est appelée multithreading et conduit à un débogage très complexe.

Les problèmes de blocage et de famine dans le multithreading peuvent entraîner la défaillance d'un système.

Défauts arithmétiques

Une quantité excessive de travail ou moins de connaissances peut amener un programmeur à faire des erreurs dans les expressions arithmétiques et leurs solutions, appelées défauts arithmétiques.

La congestion du code peut rendre un programmeur incapable de lire correctement le code écrit et peut également provoquer des défauts arithmétiques.

Défauts de syntaxe

Parfois, les développeurs, lors de l'écriture du code, font des erreurs liées au style ou à la syntaxe du code.

Ces erreurs peuvent être aussi petites que l'omission d'un symbole.

Un exemple de défauts de syntaxe peut être l'omission du point-virgule (;) lors de l'écriture du code en C++ ou Java.

Défauts d'interface

L'interaction entre l'utilisateur et le logiciel peut être affectée par des défauts. On parle alors de défauts d'interface.

Des interfaces compliquées, peu claires ou basées sur une plate-forme peuvent entraîner des défauts d'interface dans le logiciel.

Métriques de défaut

L'estimation précise de la qualité, du coût et de l'efficacité du projet testé est fondamentale.

Defect Metrics nous aide à estimer les aspects mentionnés précédemment de l'application logicielle.

Métriques de densité de défauts

L'épaisseur ou la concentration de défauts dans le logiciel est appelée métrique de densité de défauts.

Les mesures de densité de défauts peuvent être définies comme le pourcentage du nombre de défauts identifiés par exigence ou cas de test.

Formule:

|__+_|

Où la taille est le nombre de cas de test requis.

Exemple:

Supposons que dans un logiciel, il existe 1000 cas de test, dont 600 sont réussis et 400 échouent. La densité de défauts, dans ce cas, sera,

|__+_|

Ainsi, la densité de défauts est de 40 %. Ainsi, 40 % des cas de test ont échoué lors de l'exécution, ou seulement 40 % de la conception des tests ont pu détecter des défauts.

Mesures totales des défauts

L'évaluation relative des défauts totaux par rapport à la taille du module et à la complexité du logiciel peut expliquer l'efficacité des efforts de test.

Personne ne peut croire un développeur qui dit zéro défaut trouvé dans n'importe quel logiciel.

Répartition des défauts par priorité et gravité

Nous avons déjà compris que les défauts sont classés en fonction de leur priorité et de leur gravité.

Si tous les défauts identifiés sont de faible gravité ou des défauts prioritaires, cela signifie que l'équipe de test n'a pas testé le système correctement.

Le nombre total de défauts donne une bonne idée des efforts de test, et la priorité et la gravité peuvent aider à la qualité des tests et de la construction.

Densité pondérée des défauts

La gravité moyenne des défauts par cas de test peut être définie comme la densité pondérée des défauts.

Formule:

|__+_|

Où la taille est le nombre de cas de test ou d'exigences.

En fonction de la gravité, les poids 5, 3 et 1 sont attribués.

Coût de la recherche d'un défaut

Qu'il s'agisse de développement ou de test, le coût joue un rôle essentiel dans tout projet.

Si un client paie des sommes énormes, il s'attend à ce que le logiciel livré soit sans défaut et efficace.

Formule:

|__+_|

Le montant total peut être calculé à l'aide des ressources complètes, des taux de facturation et de la durée des tests.

Efficacité d'élimination des défauts

La compétence de l'équipe de test pour supprimer et identifier efficacement le nombre maximum de défauts avant d'envoyer le logiciel dans la phase suivante est appelée métrique d'efficacité de suppression des défauts.

Formule:

|__+_|

Exemple:

Considérez un logiciel avec 200 défauts dans la phase initiale. Après avoir corrigé, retesté et effectué des tests de régression sur le logiciel, l'équipe d'acceptation des utilisateurs teste et trouve 40 autres défauts qui auraient pu être identifiés et résolus lors des phases de test précédentes. Ces 40 défauts ont fui dans les phases suivantes et n'ont pas été retirés du système. Ainsi,

|__+_|

Ainsi, l'équipe de test du logiciel n'a pu identifier et corriger que 83,33 % des défauts totaux et a divulgué le reste de 16,67 % dans les phases suivantes.

Métriques de fuite de défauts

Contrairement à la suppression des défauts, les métriques de fuite de défauts montrent le pourcentage de défauts qui ont fui de l'étape actuelle des tests à la phase suivante ou suivante.

Les métriques de fuite de défauts doivent être minimales pour améliorer la valeur de l'équipe.

Formule:

|__+_|

Exemple:

Considérez un logiciel avec 200 défauts dans la phase initiale. Après avoir corrigé, retesté et effectué des tests de régression sur le logiciel, l'équipe d'acceptation des utilisateurs teste et trouve 40 autres défauts qui auraient pu être identifiés et résolus lors des phases de test précédentes. Ces 40 défauts ont fui dans les phases suivantes et n'ont pas été retirés du système. Ainsi,

|__+_|

Par conséquent, 16,67 % des défauts ont été divulgués dans la phase suivante.

Âge du défaut

Le cycle de vie des défauts commence à partir de l'identification d'un nouveau défaut et se termine lorsqu'ils sont corrigés ou conservés pour la prochaine version et documentés.

L'âge du défaut est le laps de temps entre l'identification et la fermeture d'un défaut.

|__+_|

Le défaut peut être en heures ou en jours - plus l'âge du défaut est petit, meilleure est la réactivité de l'équipe de test.

Classification des défauts

Tous les défauts ne sont pas identiques ou ne nécessitent pas l'attention immédiate d'un testeur.

C'est pourquoi il est essentiel de classer les défauts.

Les défauts sont définis avec un niveau de gravité ou de priorité afin que l'équipe de développement puisse comprendre lequel résoudre en premier.

1. Gravité du défaut

Gravité des défauts ou gravité des bogues , c'est-à-dire en termes simples, peut être expliqué comme un impact que le défaut a sur le développement ou l'exécution du logiciel.

Selon l'ISTQB, la gravité du défaut peut être définie comme le degré d'impact du défaut sur le développement ou le fonctionnement d'un composant d'un système ou de l'ensemble du système.

Il est de la responsabilité de l'équipe d'AQ de définir le niveau de gravité de chaque défaut identifié.

Grâce à des mesures efficaces de gravité des défauts, l'équipe d'assurance qualité peut résoudre les défauts critiques et autres gravités du système afin de contrôler l'impact commercial potentiel de l'utilisateur final.

Exemple:

L'orthographe de Ajouter au panier est incorrecte est un défaut non critique, mais la fonctionnalité d'Ajouter au panier qui ne fonctionne pas sur un site Web de commerce électronique est un défaut critique.

Pourquoi c'est important?

L'importance de définir les niveaux de gravité du problème est :

  • Les équipes de test peuvent déterminer l'efficacité du processus de test.
  • Le mauvais fonctionnement de différents aspects du logiciel peut être facilement vérifié.
  • Le suivi des bogues sera augmenté en utilisant la gravité des défauts, ce qui améliorera la qualité du logiciel.
  • L'équipe d'assurance qualité peut déterminer et tester les défauts les plus graves en premier.
  • Les systèmes de surveillance et de gestion des bogues peuvent devenir plus systématiques et organisés en utilisant la gravité des défauts ou des bogues.
  • Les défauts peuvent être attribués plus efficacement en fonction des compétences et du niveau d'expérience du développeur, ainsi que du niveau de gravité et du niveau.

Types de défauts basés sur la gravité du défaut

Sur la base de la gravité des défauts, il existe quatre niveaux de gravité trouvés dans les logiciels :

(i) Critique

Représenté par S1, il s'agit du niveau de gravité le plus élevé ou de la gravité de priorité la plus élevée que l'on puisse trouver dans un logiciel.

Ces types de défauts entravent entièrement l'exécution du logiciel et provoquent parfois un arrêt complet du système.

Il est de la plus haute importance de supprimer ces défauts car ils n'ont pas de solution de contournement et perturbent les tests ultérieurs du logiciel.

Pour Exemple , même après avoir entré l'identifiant et le mot de passe corrects, l'utilisateur ne peut pas se connecter et accéder à une application est un défaut critique.

(ii) Majeur

Un défaut important se produit lorsque le système reçoit un ensemble d'entrées mais ne peut pas fournir l'ensemble de résultats souhaité. S2 le représente.

Ces défauts peuvent provoquer le plantage d'un système, mais laissent encore quelques fonctionnalités utilisables, laissant ainsi une petite marge pour les contourner pour des tests supplémentaires.

Pour Exemple , ne pas pouvoir ajouter plus d'un article dans le panier sur un site de commerce électronique est un défaut important mais pas critique car l'utilisateur pourra toujours acheter le seul article.

(iii) Mineur

Lorsqu'un composant ne produit pas les résultats attendus ou ne répond pas à ses exigences mais a un impact négligeable sur l'ensemble du système, on parle de défaut mineur ou modéré.

Représentés par S3, les défauts mineurs n'affectent qu'une petite partie de l'application, ce qui provoque un comportement anormal du logiciel, mais affecte le système dans son ensemble.

Pour Exemple , même après avoir commandé les articles, l'article est visible dans les articles commandés et peut être suivi, mais un message de la fenêtre d'invite Article non commandé s'affiche. Il s'agit d'un défaut mineur, car l'invite est simplement la mauvaise.

(iv) Insignifiant

Les erreurs triviales de défauts sont des défauts de faible gravité qui n'affectent que l'aspect et la convivialité du logiciel, mais n'affectent aucune fonctionnalité ou dysfonctionnement du système ou du logiciel.

Ce défaut de niveau de gravité S4 peut ne pas affecter la fonctionnalité mais reste un défaut valide et doit être corrigé.

Pour Exemple , Un mauvais alignement ou une faute d'orthographe dans la page Termes / Conditions du site Web est un défaut trivial.

Attention avant de définir un niveau de gravité

Comme la gravité des défauts est un aspect essentiel des tests logiciels, une grande prudence doit être exercée lors de leur définition.

Chaque niveau de gravité doit être clairement défini, car cela pourrait entraîner des différences entre l'équipe de développement et l'équipe d'assurance qualité.

2. Priorité des défauts

L'importance ou l'urgence de résoudre un défaut est déterminée par la priorité du défaut ou du bogue.

le chef de projet attribue la priorité de chaque défaut en fonction des besoins commerciaux de l'utilisateur et de la gravité du défaut.

La priorité d'un défaut est subjective car elle est déterminée après comparaison avec d'autres défauts.

Outre le chef de projet, la priorité supérieure ou inférieure des défauts est définie par les propriétaires de produits, les analystes métier et les parties prenantes métier.

Types de défauts basés sur la priorité des défauts

Il existe quatre niveaux de priorité pour classer les défauts :

(i) Immédiat

Les défauts qui affectent le système et les exigences de l'entreprise doivent être corrigés immédiatement.

Représentés par P1, ces défauts empêchent le système d'exécuter ses fonctions de base ou rendent le système instable, limitant ainsi tout autre test.

Tous les défauts de gravité critique ont une priorité immédiate à moins que la séquence ne soit redéfinie par les entreprises/les parties prenantes.

Pour Exemple , le nom d'une entreprise mal orthographié n'est peut-être pas un défaut de gravité élevée ou critique, mais il s'agit d'une priorité immédiate car il affecte son activité.

(ii) Élevé

Ces défauts P2 ou de haute priorité sont les suivants à résoudre une fois que les problèmes de priorité immédiate sont résolus.

Les défauts qui ne correspondent pas à leurs « critères de sortie » ou qui font qu'un composant s'écarte des mesures de performance prédéfinies. Ces mesures peuvent dépendre du codage ou de facteurs environnementaux.

L'entreprise ou le client n'est pas directement affecté par le défaut, mais il est toujours urgent de le réparer.

Pour Exemple , ne pas ajouter de produits à un panier appartient à une catégorie hautement prioritaire.

(iii) Moyenne

Les défauts qui ne relèvent pas de la catégorie élevée et immédiate relèvent de la priorité moyenne.

Ces défauts doivent être corrigés dès que ceux ci-dessus sont corrigés car ils pourraient contenir des défauts liés à la fonctionnalité.

Représentés par P3, ces défauts peuvent parfois inclure des erreurs triviales ou cosmétiques telles que des messages d'erreur erronés lors d'une panne.

Ces défauts pourront également être corrigés dans les prochaines versions.

Pour Exemple , même après une connexion réussie, un message d'erreur d'identifiant de connexion/mot de passe invalide s'affiche, il s'agit alors d'une erreur de priorité moyenne.

(iv) Faible

Il s'agit principalement de défauts de faible gravité qui ne nécessitent pas une attention immédiate et peuvent être résolus une fois que d'autres défauts critiques et essentiels sont corrigés.

Représentés par P4, ces défauts peuvent être des erreurs de frappe, des erreurs cosmétiques ou des suggestions liées à des améliorations pour améliorer l'expérience utilisateur.

Puisqu'ils ne nécessitent pas une attention immédiate, ils peuvent être résolus à l'avenir.

Pour Exemple , l'onglet contact n'est pas situé sur la page d'accueil et est caché dans l'autre menu de la barre de navigation.

Consignes avant de sélectionner la priorité et la gravité

Pour une transaction et une communication fluides entre les équipes de développement et de test, certaines directives doivent être décidées avant de choisir le niveau de gravité et de priorité.

Certaines de ces directives sont :

  • Il est essentiel de comprendre le concept de priorité de gravité.
  • Avant de décider de l'impact du défaut, comprenez la priorité du défaut pour l'utilisateur.
  • Lister toutes les séquences liées à l'apparition et au fonctionnement du défaut.
  • Tout d'abord, isolez le défaut, puis déterminez la profondeur de son impact.
  • En fonction de la complexité et du temps de vérification, déterminez le temps nécessaire pour corriger chaque défaut.
  • Déterminez la classe d'entrée prise en charge par le défaut.
  • Attribuez un niveau de gravité en fonction du type de défaut car il déterminera également sa priorité.

Différence entre la gravité du défaut et la priorité

Gravité du défaut Priorité des défauts
C'est le degré d'impact d'un défaut sur le système.C'est l'ordre dans lequel le développeur résoudra le défaut.
Les testeurs QA définissent le niveau de gravité.Les chefs de produit et les autres parties prenantes de l'entreprise définissent la séquence des priorités.
La sévérité, une fois décidée, ne change pas avec le temps.La priorité des défauts peut changer en fonction de la comparaison avec d'autres défauts.
Il est de quatre types : Critique Majeur Mineur TrivialIl est de quatre types :ImmédiatÉlevéMoyenFaible
Il indiquait la gravité du défaut.Il indique l'importance commerciale du défaut et le délai dans lequel il doit être corrigé.
La gravité est basée sur la fonctionnalité affectée par le défaut.La priorité est basée sur la valeur métier affectée par le défaut.
Pendant le SIT, les défauts sont corrigés en fonction de la gravité d'abord, puis de la priorité.Pendant l'UAT, les défauts sont corrigés en fonction de la priorité.

Combiner gravité et priorité

Étant donné que la priorité et la gravité sont deux des classifications les plus cruciales des défauts, de nombreuses organisations combinent la gravité et le niveau de priorité pour définir différents niveaux.

1. Haute priorité, haute gravité

Les défauts critiques ou majeurs des exigences commerciales entrent dans cette catégorie et doivent être corrigés immédiatement car aucun autre test ne peut avoir lieu tant qu'ils ne sont pas corrigés.

Pour Exemple , après avoir payé des produits dans votre panier sur un site e-commerce, l'article n'est toujours pas commandé, mais le paiement de votre compte a été déduit.

2. Haute priorité, faible gravité

Les défauts qui n'affectent pas l'exigence fonctionnelle mais affectent l'exigence métier ou l'expérience utilisateur, alors ces défauts entrent dans cette catégorie.

Pour Exemple , les polices et l'alignement du site Web ne sont pas conviviaux, moins de clients cliqueront sur le site Web, ce qui affectera l'entreprise.

3. Haute gravité, faible priorité

Ces défauts ont une sévérité élevée en termes d'exigences fonctionnelles mais n'affectent pas les exigences métier.

Pour Exemple , l'application n'est accessible qu'à partir de versions plus récentes d'un navigateur particulier présentant un défaut de gravité élevée mais de faible priorité.

4. Faible gravité, faible priorité

Les fautes d'orthographe, la police, le désalignement sur les pages ultérieures de l'application auxquelles les utilisateurs n'accéderont pas fréquemment appartiennent à cette catégorie.

Pour Exemple , les fautes d'orthographe dans la page des termes et conditions ou les pages de la politique de confidentialité sont des défauts de faible gravité et de faible priorité.

3. Probabilité de défaut

La probabilité d'un défaut est la probabilité de la visibilité du défaut par l'utilisateur.

La probabilité de défaut peut également être appelée Visibilité des défauts, Visibilité des bogues ou Probabilité de bogue et est exprimée en pourcentage (%).

La probabilité d'un défaut est déterminée en fonction d'une caractéristique ou d'un composant particulier, mais pas de l'ensemble du système.

Ainsi, un défaut à faible probabilité peut être présent dans une fonctionnalité largement utilisée, alors qu'un défaut à forte probabilité est rarement utilisé.

Types de probabilité de défaut

(i) Élevé

Les défauts à forte probabilité sont ceux qui peuvent être facilement rencontrés par les utilisateurs.

Ces défauts sont présents dans presque toutes les fonctionnalités d'accès utilisateur.

(ii) Moyen

Lors du test d'une fonctionnalité particulière, si un défaut est rencontré par plus de 50 % de ses utilisateurs, le défaut est classé comme un défaut de probabilité moyenne.

(iii) Faible

Les défauts à faible probabilité sont rencontrés par très peu d'utilisateurs et n'ont pas besoin d'être résolus immédiatement.

Cycle de vie des défauts

Un cycle de vie de défaut ou cycle de vie de bogue a défini un ensemble d'états qu'un défaut subit pendant toute sa forme de vie, étant trouvé résolu/rejeté/différé.

Le cycle de vie d'un bogue peut être compris comme le cycle de croissance d'un bogue défini pour faciliter la coordination et la communication entre les différentes équipes.

Le cycle de bogue varie selon l'organisation, les outils (JIRA, QC, etc.) et le type de projet.

États de défaut

Il existe différents états dans le cycle de vie des défauts ou cycle de vie des bogues dans les tests de logiciels. Ils sont les suivants :

Nouvelle: Lorsque l'équipe de test rencontre une erreur ou une erreur dans l'application développée, le cycle de bogue logiciel démarre et le bogue est dit être dans un état Nouveau.

Attribué: Une fois le défaut trouvé, le responsable du test ou le chef de projet approuve le défaut et l'attribue à l'équipe de développement en changeant le statut du défaut en Attribué.

Ouvert: Lorsque le défaut est maintenu en cours par l'équipe de développement, un état Ouvert lui est attribué. Les développeurs peuvent commencer à corriger le bogue s'il n'entre pas dans ces catégories du cycle de vie du bogue :

    Rejeté:Si le développeur considère que le bogue n'est pas authentique ou qu'il s'agit d'une erreur de codage, le statut du défaut est modifié en Rejeté. Le défaut peut être rejeté s'il s'agit d'un doublon, non reproductible ou pas du tout un défaut.Dupliquer:Si le défaut se répète ou correspond à un autre défaut dans le journal des défauts avec le même concept, alors ces défauts sont placés dans un état Dupliqué.Différé :Si le défaut n'est pas d'une priorité plus élevée et peut être reporté pour être corrigé dans des versions ultérieures, le statut du défaut dans le cycle de bogue passe à Différé. Certains des cas dans lesquels un défaut peut être affecté à l'état différé sont :
    • Le défaut devrait être corrigé dans les versions ultérieures.
    • Le bogue est mineur et ne nécessite pas une attention immédiate.
    • Le client peut modifier l'exigence du client.
    • Le bogue n'est pas lié à la version actuelle du logiciel.
    Pas un bogue :Lors du test du défaut, si le bogue n'affecte pas l'application, le défaut reçoit le statut Pas un bogue dans le cycle de vie du défaut.

Fixé: Après avoir résolu le défaut, l'équipe de développement transmet le défaut à l'équipe de test pour un nouveau test en lui attribuant le statut Corrigé.

En attente d'un nouveau test : Lorsque l'équipe de test reçoit le défaut à l'état corrigé de l'étape précédente du cycle de vie du défaut, le bogue se voit attribuer le statut de nouveau test en attente.

Retestez : Une fois que le nouveau test de l'application a commencé pour vérifier si le défaut a été corrigé ou non, le défaut se voit attribuer le statut Retest. Une fois le nouveau test du défaut terminé, l'équipe de test peut lui attribuer l'un des deux états du cycle de bogue :

Rouvrir: Si le défaut n'est pas résolu même après un nouveau test, le test attribue le statut Rouvrir au bogue et le renvoie à l'équipe de développement.

Vérifié : Si le défaut a été entièrement résolu, le défaut se voit attribuer le statut Vérifié, ce qui implique que le défaut a été résolu et vérifié par l'AQ.

Fermé: Une fois que le bogue est Corrigé par le développeur et Vérifié par le testeur, le statut du défaut passe à Fermé. Le cycle de vie du défaut prend également fin avec l'achèvement de cet état.

Directives pour le cycle de vie des défauts

Il existe des directives spécifiques à prendre en compte avant de définir les états du cycle de vie des défauts. Ils sont:

  • Un chef d'équipe ou un chef de projet doit s'assurer que les membres de l'équipe connaissent leur responsabilité envers le défaut et son statut.
  • Le statut du défaut doit être attribué et maintenu.
  • Assurez-vous que l'ensemble du cycle de vie des défauts est bien documenté et compris par chaque membre de votre équipe.
  • Avant de modifier le statut du défaut, une raison plausible et détaillée doit être spécifiée.

Analyse des causes profondes des défauts

Maintenant que nous avons vu les défauts et la classification du cycle de vie des défauts, examinons l'analyse des causes profondes (RCA) des défauts pour comprendre leurs causes profondes.

Si cette analyse est effectuée systématiquement, le logiciel actuel bénéficiera non seulement mais également à l'ensemble de l'organisation.

L'analyse des causes profondes permet de détecter rapidement les défauts, réduisant ainsi le coût global de leur résolution à long terme. Cela peut être fait sur des défauts de conception, des défauts de test, ainsi que des défauts de produit.

Cependant, rappelez-vous que l'analyse des causes profondes ne vise pas à traiter ou à résoudre le défaut, mais uniquement à les trouver ou à les diagnostiquer.

En considérant une étude de cas d'un mécanicien de réfrigérateur, nous pouvons mieux comprendre l'analyse des causes profondes. Un bon mécanicien trouvera d'abord la cause profonde des problèmes de notre réfrigérateur, puis utilisera les méthodes appropriées pour y remédier.

L'analyse des causes profondes peut être considérée comme un mécanisme d'ingénierie inverse dans lequel la chaîne d'événements revient en arrière, à partir de la dernière action possible.

Processus (méthode 5W1H)

À l'aide des quatre questions ci-dessous, l'analyse des causes profondes peut être effectuée :

Quoi?

La première et essentielle étape du processus d'analyse des causes profondes consiste à déterminer QUEL est le problème.

Il sera impossible de déterminer la cause première du problème si nous ne connaissons pas exactement le problème.

Pour Exemple , les utilisateurs de votre site Web se sont plaints de ne pas pouvoir se connecter avec le bon identifiant et le bon mot de passe.

Lorsque?

L'étape suivante consiste à déterminer quand un problème particulier s'est produit.

Par exemple, les utilisateurs n'ont pas pu se connecter entre 4h00 et 5h00.

Où?

Cette étape détermine où le problème s'est produit, c'est-à-dire sur quelle page du site Web ou l'emplacement sur le logiciel.

Pour Exemple , les utilisateurs n'ont pas pu se connecter sur la page de connexion, le problème s'est donc produit sur la page de connexion.

Qui?

Cette question concerne la personne qui a participé à la résolution du problème.

Pour Exemple , l'administrateur du serveur était responsable de la maintenance du serveur, ce qui a entraîné des problèmes de connexion avec les utilisateurs.

Pourquoi?

Cette étape consiste à identifier la raison de l'apparition du problème et l'analyse détaillée de sa cause profonde sous-jacente.

Pour Exemple , les serveurs étaient arrêtés pour maintenance, ce qui interférait avec la connexion des utilisateurs.

Comment?

Il s'agit de la dernière étape du processus d'analyse des causes profondes. Cela nous aide à garantir que le problème ne se reproduira pas à l'avenir.

Pour Exemple , s'assurer qu'un e-mail ou un SMS est envoyé à tous les utilisateurs enregistrés chaque fois que le système est en maintenance nous aidera à prévenir son apparition future.

Analyse étape par étape des causes profondes

Il est essentiel de mettre en place une approche structurelle et organisée pour l'analyse des causes profondes.

Les étapes à suivre sont :

1. Former une équipe d'analyse des causes profondes

Le travail de chaque équipe consiste à avoir un responsable RCA qui collectera les détails liés aux problèmes et lancera le processus RCA.

Le personnel de chaque équipe, c'est-à-dire les exigences, les tests, la qualité, la conception, le support et la maintenance et la documentation, doit faire partie de l'équipe RCA.

Chaque équipe sera chargée de retracer le défaut et de déterminer ce qui n'a pas fonctionné dans ses phases avec le rapport d'incident, les preuves du problème, etc.

2. Définir

Une fois que le rapport d'incident, les preuves du problème et d'autres documents ont été recueillis, l'équipe RCA étudiera alors le problème et tentera de déterminer :

La séquence d'événements menant l'utilisateur au problème,

  • Systèmes impliqués dans le problème,
  • La période du problème,
  • Impact du problème, et
  • La personne impliquée dans le problème.

3. Identification

Après avoir défini le problème, l'équipe RCA peut utiliser l'analyse Fishbone ou 5 Why Analysis pour déterminer la cause première.

Le responsable RCA aidera ensuite à mettre en place un ensemble de règles pour le bon fonctionnement de la session de brainstorming.

4. Mise en œuvre de l'action corrective de cause racine (RCCA)

Avec l'aide du responsable de livraison, la date de livraison et les versions nécessitant le correctif seront définies, après quoi l'action de correction commencera.

Par exemple, lorsqu'une équipe de support fournit aux utilisateurs un correctif pour leur problème, ce sera temporaire. La mise en œuvre de RCCA fournira une solution permanente afin que le défaut ne se reproduise plus à l'avenir.

5. Mise en œuvre de l'action préventive de cause racine (RCPA)

Le RCPA s'occupe de prévenir de tels problèmes similaires à l'avenir avec un manuel d'instructions mis à jour, une liste de contrôle d'évaluation mise à jour pour l'équipe, un ensemble de compétences amélioré, etc.

Avantages de l'analyse des causes profondes

RCA aide à

  • Réduire les retouches sur les mêmes problèmes encore et encore.
  • Prévenir les problèmes récurrents.
  • Réduire le coût de résolution des problèmes.
  • Fournir aux clients et aux parties prenantes un logiciel à défaut négligeable

Erreur vs défaut vs échec

Généralement, les débutants en test ne savent pas quel terme utiliser pour l'anomalie ou la sortie inattendue dans le système/l'application.

Ils appellent ces anomalies des erreurs, des bogues, des défauts ou des échecs et utilisent ces termes de manière interchangeable sans comprendre clairement ce qu'ils signifient.

Voyons comment les erreurs, les défauts et les échecs diffèrent les uns des autres.

termes

Tout d'abord, nous discuterons de quelques-uns des différents termes utilisés par les testeurs débutants.

Erreur: Une erreur peut être une erreur, un malentendu ou une idée fausse de la part du développeur. Les développeurs peuvent être des programmeurs, ingénieurs logiciels , analystes et testeurs. L'erreur provoque un changement de fonctionnalité dans le programme. Par exemple, il peut arriver que lors de l'écriture d'un programme, le nom de la variable soit mal utilisé. Cela peut entraîner une boucle ou une autre erreur de syntaxe.

Défaut: C'est le point où l'application ou le logiciel s'écarte des exigences du client. Il peut s'agir de tout problème lié au comportement et aux fonctionnalités externes ou internes du système.

Punaise: L'erreur trouvée par le testeur est appelée un bogue. Une erreur, lorsqu'elle n'est pas gérée correctement, peut être envoyée au client et entraîner un mauvais fonctionnement du programme et produire des résultats inattendus. Cela peut également entraîner des plantages dans l'application.

Tort: Lorsque le logiciel développé n'est pas implémenté conformément aux exigences, on dit qu'il est faux.

Supplémentaire: C'est l'aspect indésirable ou non spécifié du logiciel qui n'a pas été spécifié dans les exigences de l'utilisateur. Cet attribut peut être requis ou non par l'utilisateur et est donc considéré comme un défaut.

La faute: Les erreurs peuvent conduire à des pannes. Il s'agit d'une étape, d'un processus ou d'une définition incorrects dans le programme qui provoque un mauvais comportement. Une erreur est une anomalie qui fait que le programme s'exécute de manière inattendue, imprévue ou involontaire.

Manquant: Contrairement à extra, il manque une catégorisation des défauts lorsque le logiciel ne répond pas aux exigences de l'utilisateur. Il se produit lorsqu'une ou plusieurs spécifications du besoin de l'utilisateur ne sont pas mises en œuvre.

Échec: Lorsqu'un défaut atteint le client final, cela s'appelle un échec. Elle est définie comme l'incapacité du système ou du composant logiciel à fonctionner comme il est censé le faire, c'est-à-dire dans les limites des exigences spécifiées.

Introduction à l'erreur, au défaut et à l'échec

image 617dd28eb28f8

Quelqu'un peut comprendre l'erreur, le défaut et l'échec avec l'exemple suivant :

Lors de la création d'un logiciel de présence, le développeur oublie d'ajouter la fonctionnalité demi-journée. C'est une erreur ou une erreur. Cela entraîne un défaut ou une panne ou un bogue dans le logiciel car cette fonctionnalité est essentielle. Maintenant, si cette application est développée et livrée au client, le logiciel sera marqué comme absent si quelqu'un dans l'organisation prend une demi-journée. Ainsi, le système ne parvient pas à faire ce qu'il était censé faire, ce qui provoque un échec.

Erreur

L'erreur est humaine.

Une erreur est une erreur humaine causée par une erreur, un malentendu ou une idée fausse de la part du développeur.

Une seule erreur peut entraîner une série de défauts dans le logiciel.

Cela peut être dû à :

  • Une erreur logique du développeur provoque une erreur.
  • Défaut de conception par un architecte.
  • Les habitudes humaines comme la léthargie, la procrastination ou autres provoquent une erreur.
  • Des erreurs peuvent être causées par des informations incorrectes ou insuffisantes des clients.
  • Une mauvaise interprétation des exigences par un analyste métier provoque une erreur.
  • Une mauvaise communication des exigences entre l'analyste et le développeur entraîne des erreurs.

Types d'erreur

    Erreur syntaxique :Les erreurs liées à la grammaire ou à l'orthographe dans une phrase qui sont très évidentes lors du test de l'interface graphique du logiciel sont des erreurs syntaxiques.Erreur de gestion d'erreur :Les erreurs qui se produisent lorsque les erreurs ne sont pas gérées correctement sont appelées erreur de gestion des erreurs. Lorsqu'un utilisateur interagit avec un système, une erreur peut se produire. Si cela n'est pas géré correctement, cela prête à confusion et est qualifié d'erreur de gestion des erreurs.Erreur matérielle :Il peut arriver que le composant matériel utilisé avec le logiciel ne soit pas compatible ou qu'il manque des pilotes, puis des erreurs matérielles se produisent.Erreur d'interface utilisateur :Lorsque l'utilisateur interagit avec le système, il peut être confronté à des erreurs de fonctionnalité manquantes ou incorrectes. Celles-ci sont appelées erreurs d'interface utilisateur.Erreur de test :L'échec est l'analyse ou le signalement d'un bogue qui se produit pendant l'exécution du test est appelé une erreur de test.Erreur de calcul :Les erreurs qui se produisent en raison de formules incorrectes, d'une inadéquation des types de données, d'une logique défectueuse ou d'autres sont appelées erreurs de calcul.Erreur de contrôle de flux :Lorsque le programme se déroule dans une direction inattendue ou passe le contrôle dans la mauvaise direction, ces erreurs sont appelées erreurs de contrôle de flux. Ces erreurs entraînent boucles infinies , erreurs de syntaxe d'exécution, etc.

Causes des erreurs

Certaines raisons possibles pour lesquelles les erreurs se produisent dans un produit logiciel sont :

    Erreur humaine:Les humains sont la seule intelligence sur laquelle nous pouvons compter, et ils sont sujets aux erreurs. En faisant attention, quelques erreurs peuvent être évitées mais pas toutes.Miscommunication:Un logiciel est développé et testé par plusieurs personnes, ce qui peut entraîner des conflits qui se traduisent par une mauvaise coordination et une mauvaise communication. Les erreurs d'interprétation et les malentendus entraînent des erreurs dans le logiciel qui auraient autrement été évitées.Interfaces intra-système et inter-système :Les risques d'erreurs dans l'établissement de l'interface inter-système et intra-système sont très élevés.
      Interface intra-système –L'intégration de différents modules et fonctionnalités au sein d'un système ou d'une application entraîne des erreurs d'interface intra-système.Interface inter-système –La compatibilité entre deux applications différentes tout en travaillant ensemble peut entraîner des erreurs d'interface inter-système.
    Environnement:Les inondations, les incendies, les tremblements de terre, les tsunamis, la foudre et autres affectent le système informatique et entraînent des erreurs.Pression:Travailler avec des ressources limitées ou insuffisantes et des délais irréalistes entraînent moins de temps disponible pour les développeurs pour tester eux-mêmes le code avant de le transmettre à l'équipe de test.Inexpérience:La répartition des tâches dans un projet doit être fonction de l'expérience ou des compétences du membre de l'équipe. Si cela n'est pas suivi, cela pourrait conduire à des erreurs car les membres inexpérimentés ou insuffisamment qualifiés n'auront pas une bonne connaissance de la tâche.Complexité:Des codes, des conceptions, une architecture ou une technologie très complexes peuvent ouvrir la voie à des bogues critiques, car un esprit humain ne peut prendre qu'un certain niveau de complexité.Technologie inconnue :Les développeurs et les testeurs qui ne se tiennent pas au courant des récents développements technologiques seront confrontés à un problème lors de projets basés sur des technologies en dehors de leur domaine de connaissances et provoqueront ainsi une erreur.

Erreur vs défaut vs échec

Erreur Défaut Échec
C'est une erreur.L'erreur provoque un défaut.Le défaut conduit à l'échec.
L'action humaine génère des résultats inattendus.Le produit ou le logiciel présente une déficience spécifique en raison de laquelle il n'est pas en mesure de répondre aux spécifications requises.Le composant ou le système ne parvient pas à exécuter les activités requises dans les critères prédéfinis.
Toutes les erreurs ne conduisent pas à des défauts. Par exemple, une simple faute de grammaire n'est pas considérée comme un défaut.Tous les défauts ne conduisent pas à des échecs. Par exemple, certaines conditions préalables peuvent être requises par une fonction particulière mais ne sont pas nécessaires et ne provoquent donc pas d'échec.Toutes les pannes ne sont pas critiques. Par exemple, le client peut avoir besoin d'améliorer la version du système tout en utilisant le logiciel car la version du client est obsolète.

Derniers mots

L'apparition ou l'occurrence d'un écart entraîne d'autres problèmes, et donc tout est interdépendant.

Les erreurs sont le résultat d'erreurs humaines qui entraînent des écarts par rapport aux exigences et entraînent des défauts.

Un défaut peut être critique ou non, et ne signifie donc pas nécessairement une erreur dans le code.

Il peut également s'agir d'une fonction non implémentée définie dans les exigences.

Alors, vérifiez attentivement avant de sauter à la conclusion que le code est erroné.

Rapport de défaut

Un rapport de défaut ou rapport de bogue est un document identifiant et décrivant un défaut détecté par un testeur. Le rapport de défaut peut être utilisé pour identifier des types de défauts similaires à l'avenir afin de les éviter.

Définir le défaut dans les tests de logiciels

Un bogue ou un défaut est le résultat ou la conséquence d'un défaut de codage qui ne répond pas aux exigences réelles.

Lorsque les testeurs effectuent des tests sur les cas de test, la variation ou l'écart du point d'application par rapport aux exigences de l'utilisateur final qui entraîne des résultats incorrects ou inattendus est un défaut.

Les problèmes, les bogues, les problèmes ou les incidents sont généralement appelés noms pour les défauts de test de logiciel.

Définir le rapport de défaut

La documentation qui spécifie l'occurrence, l'état et la nature du défaut de manière transparente afin que les développeurs puissent facilement le reproduire et le corriger est appelée un rapport de défaut.

Le document contient des détails sur le défaut, tels que sa description, le nom du testeur qui l'a trouvé, la date à laquelle le défaut a été trouvé, le développeur qui l'a corrigé, etc.

Modèle de rapport de défaut

Le modèle de rapport de défaut peut varier d'un outil à l'autre. Cependant, un modèle de rapport de défaut général sera le suivant :

identifiant Identifiant unique automatisé ou manuel pour identifier le défaut
Projet Nom du projet
Produit Nom du produit
Version finale Version de lancement du produit
Module Le module où le défaut a été détecté.
Version de construction détectée Version de construction du produit où le défaut a été détecté.
Résumé Un résumé clair et concis du défaut constaté.
La description Une description simple et complète du défaut. N'utilisez rien de façon répétée ou n'utilisez pas de mots compliqués.
Étapes à reproduire Description étape par étape de la reproduction des défauts en plusieurs étapes.
Résultats actuels Les résultats réels ont été obtenus après avoir suivi les étapes.
Résultats attendus Ces résultats devaient être obtenus après avoir suivi les étapes.
Pièces jointes Des informations supplémentaires telles que des captures d'écran et des journaux.
Remarques Commentaires supplémentaires liés au défaut.
Probabilité de défaut La probabilité du défaut.
Gravité du défaut La gravité du défaut.
Rapporté par Le nom de la personne qui a signalé le défaut.
Assigné à Le nom de la personne à qui le défaut est attribué pour analyse ou correction.
Statut État du défaut
Version de construction fixe Version de construction du produit après correction du défaut.

Processus de gestion des défauts

Un processus systématique d'identification et de correction des bogues est appelé processus de gestion des défauts.

Il y a les six étapes suivantes dans un cycle de gestion des défauts :

  • Découverte – de défaut
  • Catégorisation – du défaut
  • Correction/Résolution – du défaut par les développeurs
  • Vérification – par des testeurs
  • Fermeture – de défaut
  • Rapport de défaut
image 617dd28f1461c

1. Découverte

Cette étape consiste à découvrir un maximum de défauts par les testeurs avant que l'utilisateur final ne les découvre.

Une fois que le défaut est reconnu et accepté par les développeurs, il peut être qualifié de découvert.

2. Catégorisation

La catégorisation consiste à diviser divers défauts en fonction de leur priorité afin que les développeurs puissent les corriger en conséquence.

Il existe quatre catégories :

    Critique:Ces défauts nécessitent une correction immédiate car ils peuvent causer des dommages importants au produit s'ils ne sont pas contrôlés.Haut:Ces défauts impactent les principales caractéristiques d'un produit.Moyen:Ces défauts entraînent un écart minimal par rapport aux exigences logicielles.Meugler:Ces défauts ont un effet mineur sur le fonctionnement du produit.

3. Résolution

Dans les tests de logiciels, la correction des défauts ou la résolution des défauts est généralement un processus en quatre étapes qui permet de corriger et de suivre facilement les défauts.

Commençant par l'attribution des défauts aux développeurs, suivi du calendrier de correction des défauts, après quoi les défauts sont corrigés, le processus se termine lorsqu'un rapport de résolution est envoyé au responsable des tests.

    Mission:Le défaut à corriger est attribué à un développeur et le statut est changé en Répondant.Fixation des horaires :Selon la priorité des défauts, les développeurs créent un calendrier pour corriger les défauts.Correction du défaut :Le Test Manager compare la procédure de correction des défauts de l'équipe de développement avec son planning.Résolution:Le rapport de défaut des développeurs est envoyé au responsable des tests une fois les défauts corrigés.

4. Vérification

L'équipe de test vérifie si les défauts corrigés par l'équipe de développement ont été résolus ou non.

5. Fermeture

Après une résolution et une vérification réussies du défaut, le statut du défaut passe à fermé. Si cela ne se produit pas, les testeurs revérifient le défaut.

6. Rapports

Le conseil d'administration doit comprendre le processus de gestion des défauts et avoir le droit de connaître l'état des défauts.

Le responsable des tests prépare un rapport de défaut et l'envoie pour commentaires à l'équipe de gestion. L'équipe de gestion vérifie le processus de gestion des défauts et envoie ses commentaires ou son soutien si nécessaire.

Le signalement des défauts conduit à une meilleure communication et un meilleur suivi des défauts.

Besoin d'un processus de gestion des défauts

L'exigence d'un processus concret de gestion des défauts peut être mieux comprise à l'aide de l'exemple suivant :

Supposons qu'une application Gestionnaire de tâches est en cours de test.

Lors des tests, quelques bogues, disons 80, ont été trouvés par l'équipe de test et ont été signalés au responsable des tests.

Le responsable des tests informe l'équipe de développement des défauts, qui répondent après une semaine avec 70 défauts corrigés.

Le gestionnaire de test envoie ces informations à l'équipe de test.

L'équipe de test a répondu une semaine plus tard, déclarant que les 70 défauts avaient été corrigés, mais que 20 nouveaux étaient apparus.

Maintenant, tout ce processus peut être un peu compliqué en raison uniquement de la communication verbale. Le suivi et la correction des défauts seront difficiles.

Ainsi, un processus de gestion des défauts est nécessaire.

Signalement efficace des défauts

Les rapports de défauts doivent être générés efficacement.

Cela permet de gagner du temps et des efforts inutiles pour essayer de comprendre puis de reproduire le défaut.

Les mesures suivantes peuvent être suivies pour assurer des rapports de défauts utiles :

1. Jouez :

Une fois qu'un défaut a été découvert, reproduisez-le une fois de plus pour plus de sécurité. Si la réplication n'est pas possible, rappelez les conditions de test exactes qui ont conduit au défaut et réessayez. Cependant, si le défaut ne réapparaît toujours pas, envoyez les rapports de défaut détaillés et tous les résultats des essais pour une enquête plus approfondie.

2. Soyez précis :

Chaque action dans les rapports de défaut doit être spécifique.

Par exemple, au lieu de dire Se connecter, il devrait y avoir (1) Aller à la page d'accueil, (2) Cliquer sur le bouton de connexion, (3) Entrer l'ID utilisateur et le mot de passe, et (4) Cliquer sur Se connecter.

Si, par exemple, il existe plusieurs chemins, mentionnez le chemin exact qui a été suivi et qui a conduit au défaut.

Évitez d'utiliser des pronoms vagues comme celui-ci et précisez ce qu'il signifie.

3. Objectif :

Au lieu d'utiliser des déclarations subjectives comme l'application Mauvaise, évitez les émotions et dites objectivement Oui ou Non ou Accepté ou Rejeté.

4. Révision :

Après avoir écrit l'écriture, ne la soumettez qu'après l'avoir révisée et supprimé les fautes de frappe.

5. Souci du détail :

Fournissez des informations de manière détaillée. Les développeurs ne doivent pas manquer d'informations.

Métriques de défaut

Les métriques de défaut sont utilisées pour mesurer la qualité de l'exécution des tests. Il y a deux paramètres :

Taux de rejet de défauts (DRR) = (Nombre de défauts rejetés / Nombre total de défauts signalés) * 100

Defect Leakage Ratio (DLR) = (Nombre de défauts manqués / Nombre total de défauts du logiciel) * 100

Si les valeurs DRR et DLR sont petites, la qualité d'exécution des tests sera meilleure. Le gestionnaire de test définit les plages acceptées de ces valeurs.

Ces ratios peuvent être réduits de

Améliorer les compétences de test des membres de l'équipe.

Consacrer plus de temps à l'exécution des tests et à l'examen des résultats.

Par exemple, supposons que le projet Task Manager comporte 80 défauts, mais que l'équipe de test n'a pu en identifier que 60. Parmi ceux-ci, 10 défauts ont été rejetés par l'équipe de développement. Ainsi, 20 défauts ont été manqués.

Ainsi, le ratio DRR sera :

(10/60) * 100 = 16,66 %

Et le ratio DLR sera :

(20/80) * 100 = 25 %

FAQ sur les défauts

Qu'est-ce qu'un exemple de défaut ?

Un exemple de défaut logiciel peut être une erreur grammaticale dans l'interface utilisateur ou des erreurs de codage dans le programme.

Quel autre mot pour défaut ?

Dans les tests de logiciels, un défaut peut être appelé bogue, erreur, faute et bien d'autres.

Qu'est-ce qu'une correction de défaut ?

Un défaut est dit corrigé lorsque son statut est marqué comme clos. Le statut du défaut passe à fermé lorsqu'il est correctement vérifié ou conservé pour être corrigé dans les versions ultérieures.

Qu'est-ce que le cycle de vie des défauts ?

Le cycle de vie des défauts ou cycle de vie des bogues est le parcours du défaut depuis son identification jusqu'à sa résolution. Au cours de son cycle de vie, un défaut passe de l'identification à l'affectation à l'état actif, puis au test, à la vérification et à la fermeture. Le défaut peut également passer à l'état rejeté ou différé ou à l'état rouvert. Ces états varient d'une organisation à l'autre, selon l'outil utilisé pour les tests.

Comment contrôler les défauts ?

Les défauts peuvent être réduits par :
1. Exécution efficace de l'analyse des défauts
2. Analyse approfondie des exigences logicielles
3. Utilisation d'un logiciel de surveillance des erreurs
4. Tests de régression agressifs
5. Refactorisation fréquente du code.