Qu'est-ce que Bug?
Un bug est la conséquence / le résultat d'un défaut de codage.
Défaut dans les tests logiciels
Un défaut de test logiciel 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 à partir d'un programme 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 fine ligne de différence. Dans l'industrie, les deux sont des défauts qui doivent être corrigés et donc utilisés de manière interchangeable par certaines des équipes de test.
Lorsque les testeurs exécutent les cas de test, ils peuvent rencontrer des résultats de test contradictoires avec les résultats attendus. Cette variation des résultats de test est appelée un défaut logiciel. Ces défauts ou variations sont référencés par différents noms dans différentes organisations comme des problèmes, des problèmes, des bogues ou des incidents.
Dans ce didacticiel, vous apprendrez-
- Rapport d'erreur
- Processus de gestion des défauts
- Découverte
- Catégorisation
- Résolution
- Vérification
- Fermeture
- Rapports
- Mesures de défaut importantes
Rapport de bogue dans les tests de logiciels
Un rapport de bogue dans le test de logiciel est un document détaillé sur les bogues trouvés dans l'application logicielle. Le rapport de bogue contient tous les détails sur les bogues tels que la description, la date à laquelle le bogue a été trouvé, le nom du testeur qui l'a trouvé, le nom du développeur qui l'a corrigé, etc. Le rapport de bogue aide à identifier les bogues similaires à l'avenir afin qu'il puisse être évité.
Lors du signalement du bogue au développeur, votre rapport de bogue doit contenir les informations suivantes
- Defect_ID - Numéro d'identification unique du défaut.
- Description du défaut - Description détaillée du défaut, y compris des informations sur le module dans lequel le défaut a été détecté.
- Version - Version de l'application dans laquelle un défaut a été détecté.
- Étapes - Étapes détaillées avec des 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 Fournissez une référence aux 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é par - Nom / ID du testeur qui a signalé le défaut
- Statut - Statut du défaut, plus d'informations à ce sujet plus tard
- Fixé par - Nom / ID du développeur qui l'a corrigé
- Date de fermeture - Date à laquelle le défaut est fermé
- Gravité qui décrit l'impact du défaut sur l'application
- Priorité liée à l'urgence de la correction des défauts. La priorité de gravité peut être élevée / moyenne / faible en fonction de l'urgence de l'impact à laquelle le défaut doit être corrigé respectivement
Cliquez ici si la vidéo n'est pas accessible
Ressources
Téléchargez un exemple de modèle de rapport de défauts
Considérez ce qui suit en tant que Test Manager
Votre équipe a trouvé des bugs lors du test du projet Guru99 Banking.
Après une semaine, le développeur répond -
La semaine prochaine, le testeur répond
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.
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 comprend les étapes suivantes 1) Découverte du défaut, 2) Catégorisation des défauts 3) Correction des défauts par les développeurs 4) Vérification par les testeurs, 5) Clôture des défauts 6) Rapports de défauts à la fin du projet
Cette rubrique vous guidera sur la manière 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.
Découverte
Dans la phase de découverte, les équipes projet doivent découvrir autant de défauts que possible, avant que le client final ne puisse les découvrir. Un défaut est dit découvert et passe au statut accepté lorsqu'il est reconnu et accepté par les développeurs
Dans le scénario ci-dessus, les testeurs ont découvert 84 défauts dans le site Web Guru99.
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 Guru99 Bank. Ils les considèrent comme des défauts et signalés à l'équipe de développement, mais il y a un conflit -
Dans ce cas, en tant que Test Manager, que ferez-vous?
A) D'accord avec l'équipe de test que c'est un défaut
B) Le 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 qui 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 assumez le rôle de juge pour décider si le problème du site Web est un défaut ou non.
Catégorisation
La catégorisation des défauts aide les développeurs de logiciels à hiérarchiser leurs tâches. Cela signifie que ce type de priorité aide les développeurs à corriger d'abord les défauts qui sont extrêmement cruciaux.
Les défauts sont généralement classés par le Test Manager -
Faisons un petit exercice comme suit Glisser-déposer la priorité des défauts ci-dessous
- Critique
- Haut
- Moyen
- Faible
| 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 les appareils mobiles |
|
| 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
| Non. | Description | Priorité | Explication |
|---|---|---|---|
| 1 | Les performances du site Web sont trop lentes | Haut | Le bogue de performance peut causer d'énormes inconvénients à l'utilisateur. |
| 2 | La fonction de connexion du site Web ne fonctionne pas correctement | Critique | La connexion est l'une des principales fonctions du site Web 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 | Moyen | Le défaut affecte l'utilisateur qui utilise Smartphone pour consulter le site Web. |
| 4 | Le site Web n'a pas pu se souvenir de la session de connexion de l'utilisateur | Haut | Il s'agit d'un problème grave car l'utilisateur pourra se connecter mais ne pourra plus effectuer de transactions supplémentaires. |
| 5 | Certains liens ne fonctionnent pas | Faible | C'est une solution facile pour les développeurs et l'utilisateur peut toujours accéder au site sans ces liens |
Résolution des défauts
La résolution des défauts dans les tests logiciels est 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 le défaut à corriger selon la priorité, puis les défauts sont corrigés et enfin les développeurs envoient un rapport de résolution au gestionnaire de test. Ce processus permet de corriger et de suivre facilement les défauts.
Vous pouvez suivre les étapes suivantes pour corriger le défaut.
- Affectation : affectée à un développeur ou à un autre technicien pour corriger et a changé le statut en Répondant .
- Fixation du calendrier : 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é des défauts.
- Corriger le défaut : pendant que l'équipe de développement corrige les défauts, le Test Manager suit le processus de correction du défaut par rapport au calendrier ci-dessus.
- Signaler la résolution : obtenez un rapport de la résolution des développeurs lorsque des défauts sont corrigés.
Vérification
Une fois que l'équipe de développement a corrigé et signalé le défaut, l'équipe de test vérifie que les défauts sont réellement résolus.
Par exemple, dans le scénario ci-dessus, lorsque l'équipe de développement a signalé avoir déjà corrigé 61 défauts, votre équipe effectuerait un nouveau test pour vérifier que ces défauts étaient réellement corrigés ou non.
Fermeture
Une fois qu'un défaut a été résolu et vérifié, le défaut est changé d'état comme fermé . Sinon, vous avez envoyé un avis au développement pour vérifier à nouveau le défaut.
Rapport de défauts
Le rapport de défauts dans les tests logiciels est un processus dans lequel les responsables de test préparent et envoient le rapport de défaut à 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 signalement 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 de défaut actuelle pour obtenir des commentaires de leur part.
Mesures de défaut importantes
Revenez au scénario ci-dessus. Les équipes de développement et de test ont revu les défauts signalés. Voici le résultat de cette discussion
Comment mesurer et évaluer la qualité de l'exécution du test?
C'est une question que chaque Test Manager veut savoir. Il y a 2 paramètres que vous pouvez considérer comme suit
Dans le scénario ci-dessus, vous pouvez calculer le taux de rejet de défection (DRR) est de 20/84 = 0,238 (23,8%).
Un autre exemple, supposé que le site Web de Guru99 Bank a un total de 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 le taux de fuite de défaut (DLR) est 20/64 = 0,312 (31,2%).
Conclusion, la qualité de l'exécution des tests est évaluée via les deux paramètres suivants
La plus petite valeur de DRR et DLR est, meilleure est la qualité de l'exécution des tests. Quelle est la plage de rapport qui est acceptable ? Cette plage peut être définie et acceptée de base dans 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 de 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 tels que
- Améliorez les compétences de test du membre.
- Passez plus de temps à tester l'exécution, en particulier à examiner les résultats de l'exécution des tests.