Processus de gestion des défauts dans les tests logiciels

Qu’est-ce que le processus de gestion des défauts ?

La gestion des défauts est un processus systématique pour identifier et corriger les bogues. Un cycle de gestion des défauts contient les étapes suivantes 1) Découverte du défaut, 2) Catégorisation des défauts 3) Correction du défaut par les développeurs 4) Vérification par les testeurs, 5) Clôture du défaut 6) Rapports de défauts à la fin du projet

Ce sujet vous guidera sur la façon d'appliquer le processus de gestion des défauts au site Web du projet Guru99 Bank. Vous pouvez suivre les étapes ci-dessous pour gérer les défauts.

Processus de gestion des défauts

Étape 1) Découverte

Dans la phase de découverte, les équipes de projet doivent découvrir au fur et à mesure de nombreuses défauts comme possible, avant que le client final puisse le découvrir. Un défaut est dit découvert et passe au statut accepté quand il est reconnu et accepté par les développeurs

Dans le scénario ci-dessus, les testeurs ont découvert 84 défauts sur le site Guru99.

Découverte

Jetons un coup d'œil au scénario suivant : votre équipe de test a découvert des problèmes sur le site Web de la banque Guru99. Ils les considèrent comme des défauts et les signalent à l’équipe de développement, mais il y a un conflit –

Dans un tel cas, en tant que Test Manager, que ferez-vous ?

A) D'accord avec l'équipe de test sur le fait qu'il s'agit d'un défaut

B) Test Manager prend le rôle de juge pour décider si le problème est un défaut ou non

C) D'accord avec l'équipe de développement que ce n'est pas un défaut

Correct
Incorrect

Dans ce cas, un processus de résolution doit être appliqué pour résoudre le conflit, vous jouez le rôle de juge pour décider si le problème du site Web est un défaut ou non.

Étape 2) Catégorisation

La catégorisation des défauts aide les développeurs de logiciels à prioriser leurs tâches. Cela signifie que ce type de priorité aide les développeurs à corriger en premier les défauts qui sont extrêmement cruciaux.

catégorisation

Les défauts sont généralement classés par le Test Manager –

Faisons un petit exercice comme suit

Faites glisser et déposez la priorité du défaut ci-dessous
1) Les performances du site Web sont trop lentes
2) La fonction de connexion du site Web ne fonctionne pas correctement
3) L'interface graphique du site Web ne s'affiche pas correctement sur Mobile dispositifs
4) Le site Web n'a pas pu se souvenir de la session de connexion de l'utilisateur
5) Certains liens ne fonctionnent pas

Voici les réponses recommandées

No. Description Priorité Explication

1

Les performances du site Web sont trop lentes

Haute

Le bug de performances peut causer d’énormes désagréments à l’utilisateur.

2

La fonction de connexion du site Web ne fonctionne pas correctement

Critical

La connexion est l'une des fonctions principales du site bancaire. Si cette fonctionnalité ne fonctionne pas, il s'agit de bugs sérieux.

3

L'interface graphique du site Web ne s'affiche pas correctement sur les appareils mobiles

Moyenne

Le défaut affecte l'utilisateur qui utilise un smartphone pour consulter le site Web.

4

Le site Web n'a pas pu se souvenir de la session de connexion de l'utilisateur

Haute

Il s'agit d'un problème sérieux puisque l'utilisateur pourra se connecter mais ne pourra pas effectuer d'autres transactions.

5

Certains liens ne fonctionnent pas

Faible

Il s'agit d'une solution simple pour les développeurs et l'utilisateur peut toujours accéder au site sans ces liens.

Étape 3) Résolution des défauts

Résolution des défauts dans les tests logiciels, il s'agit d'un processus étape par étape de correction des défauts. Le processus de résolution des défauts commence par l'attribution des défauts aux développeurs, puis les développeurs planifient la correction du défaut selon la priorité, puis les défauts sont corrigés et enfin les développeurs envoient un rapport de résolution au gestionnaire de tests. Ce processus permet de corriger et de suivre facilement les défauts.

Vous pouvez suivre les étapes suivantes pour corriger le défaut.

Résolution des défauts

  • Affectation : Attribué à un développeur ou à un autre technicien pour corriger, et a changé le statut en Répondant.
  • Fixation du planning: Le côté développeur prend en charge cette phase. Ils créeront un calendrier pour corriger ces défauts, en fonction de la priorité du défaut.
  • Réparer le défaut: Pendant que l'équipe de développement corrige les défauts, le gestionnaire de tests suit le processus de correction des défauts par rapport au calendrier ci-dessus.
  • Signaler la résolution: Obtenez un rapport de la résolution des développeurs lorsque les défauts sont corrigés.

Étape 4) Vérification

Après l'équipe de développement fixé et le rapporté le défaut, l'équipe de test vérifie que les défauts sont effectivement résolus.

Par exemple, dans le scénario ci-dessus, lorsque l'équipe de développement a signalé qu'elle avait déjà corrigé 61 défauts, votre équipe effectuait un nouveau test pour vérifier que ces défauts étaient réellement corrigés ou non.

Étape 5) Clôture

Une fois qu'un défaut a été résolu et vérifié, le défaut change de statut en tant que fonds à capital fermé. Dans le cas contraire, vous devez envoyer un avis au promoteur pour vérifier à nouveau le défaut.

Étape 6) Signalement des défauts

Rapport de défauts dans les tests logiciels, il s'agit d'un processus dans lequel les responsables des tests préparent et envoient le rapport de défauts à l'équipe de direction pour obtenir des commentaires sur le processus de gestion des défauts et l'état des défauts. Ensuite, l'équipe de direction vérifie le rapport de défaut et envoie des commentaires ou fournit une assistance supplémentaire si nécessaire. Le reporting des défauts permet de mieux communiquer, suivre et expliquer les défauts en détail.

Le conseil d'administration a le droit de connaître l'état du défaut. Ils doivent comprendre le processus de gestion des défauts pour vous accompagner dans ce projet. Par conséquent, vous devez leur signaler la situation actuelle des défauts pour obtenir leurs commentaires.

Pourquoi avez-vous besoin d’un processus de gestion des défauts ?

Votre équipe a trouvé des bugs lors du test du projet Guru99 Banking.

Processus de gestion des défauts

Après une semaine, le développeur répond –

Processus de gestion des défauts

La semaine prochaine, le testeur répond

Processus de gestion des défauts

Comme dans le cas ci-dessus, si la communication du défaut se fait verbalement, les choses deviennent vite très compliquées. Pour contrôler et gérer efficacement les bogues, vous avez besoin d’un cycle de vie des défauts.

Mesures de défauts importantes

Revenez au scénario ci-dessus. Les équipes de développeurs et de tests ont examiné les défauts signalés. Voici le résultat de cette discussion

Mesures de défauts importantes

Comment mesurer et évaluer la qualité de l’exécution des tests ?

C'est une question que tout le monde Test Manager veut savoir. Il y a 2 paramètres que vous pouvez considérer comme suit

Mesures de défauts importantes

Dans le scénario ci-dessus, vous pouvez calculer le taux de rejet des défections (DRR) est 20/84 = 0.238 (23.8 %).

Autre exemple, supposons que le site Web de la Guru99 Bank ait un total 64 défauts, mais votre équipe de test ne détecte que 44 défauts, c'est-à-dire qu'ils ont manqué 20 défauts. Par conséquent, vous pouvez calculer que le taux de fuite des défauts (DLR) est de 20/64 = 0.312 (31.2%).

Conclusion, la qualité de l'exécution des tests est évaluée via les deux paramètres suivants

Mesures de défauts importantes

Plus la valeur de DRR et DLR est faible, meilleure est la qualité d'exécution des tests. Quelle est la plage de rapport qui est acceptable? Cette plage peut être définie et acceptée sur la base de la cible du projet ou vous pouvez vous référer aux métriques de projets similaires.

Dans ce projet, la valeur recommandée du ratio acceptable est 5 ~ 10 %. Cela signifie que la qualité de l'exécution des tests est faible. Vous devriez trouver des contre-mesures pour réduire ces ratios, telles que

  • Améliorez les compétences de test du membre.
  • Passer plus de temps pour l'exécution des tests, en particulier pour examiner les résultats de l'exécution des tests.

FAQs

Un bug est la conséquence/résultat d’une erreur de codage.

A Défaut dans les tests logiciels est une variation ou un écart de l'application logicielle par rapport aux exigences de l'utilisateur final ou aux exigences commerciales d'origine. Un défaut logiciel est une erreur de codage qui entraîne des résultats incorrects ou inattendus d'un logiciel qui ne répond pas aux exigences réelles. Les testeurs peuvent rencontrer de tels défauts lors de l’exécution des cas de test.

Ces deux termes ont une très mince différence. Dans l'industrie, les deux termes sont des défauts qui doivent être corrigés et donc utilisés de manière interchangeable par certains des utilisateurs. Contrôle de qualité équipes.

Lorsque les testeurs exécutent les cas de test, ils peuvent rencontrer des résultats de tests contradictoires par rapport aux résultats attendus. Cette variation dans les résultats des tests est appelée défaut logiciel. Ces défauts ou variations sont désignés par différents noms dans différentes organisations, comme des problèmes, des bogues ou des incidents.

Un rapport de bug dans les tests logiciels est un document détaillé sur les bugs trouvés dans l'application logicielle. Le rapport de bug contient tous les détails sur les bugs comme la description, la date à laquelle le bug a été trouvé, le nom du testeur qui l'a trouvé, le nom du développeur qui l'a corrigé, etc. Le rapport de bug permet d'identifier des bugs similaires à l'avenir afin qu'ils puissent être évités.

  • ID_défaut – Numéro d'identification unique du défaut.
  • Défaut Description CMS – Description détaillée du défaut comprenant des informations sur le module dans lequel le défaut a été trouvé.
  • Version - Version de l'application dans laquelle le défaut a été trouvé.
  • Pas - Étapes détaillées accompagnées de captures d'écran avec lesquelles le développeur peut reproduire les défauts.
  • Date de levée – Date à laquelle le défaut est signalé
  • Référence- où en vous Fournir une référence à des documents tels que . exigences, conception, architecture ou peut-être même des captures d'écran de l'erreur pour aider à comprendre le défaut
  • Détectée par - Nom/ID du testeur qui a signalé le défaut
  • Statut - Statut du défaut, nous y reviendrons plus tard
  • Corrigé par – Nom/ID du développeur qui l'a corrigé
  • Date de clôture – Date à laquelle le défaut est clôturé
  • Gravité qui décrit l'impact du défaut sur l'application
  • Priorité ce qui est lié à l’urgence de la correction des défauts. La priorité de gravité peut être élevée/moyenne/faible en fonction de l'urgence d'impact à laquelle le défaut doit être corrigé respectivement.

Cliquer sur missions si la vidéo n'est pas accessible

Ressources:

Téléchargez un exemple de modèle de rapport de défauts