defect management process
Introduction au processus de gestion des défauts:
Le processus et les tests plus ciblés permettront moins de logiciels bogués sur le marché.
Prévention des défauts est beaucoup plus efficace pour réduire le nombre de défauts et est également très rentable pour corriger les défauts détectés au début du processus logiciel. La plupart des organisations mènent Découverte des défauts , Suppression des défauts puis L'amélioration des processus qui est collectivement connu comme un Processus de gestion des défauts .
dispositif virtuel d'équilibrage de charge open source
Ce que vous apprendrez:
- Objectifs du processus de gestion des défauts (DMP)
- Cycle de vie de la gestion des défauts
- Processus de gestion des défauts
- Conclusion
- lecture recommandée
Objectifs du processus de gestion des défauts (DMP)
Voici les différents objectifs de ce processus:
- Empêcher le défaut
- La détection précoce
- Minimisez l'impact
- Résolution du défaut
- L'amélioration des processus
Avant d'explorer le processus de gestion des défauts, commençons par comprendre qu'est-ce qu'un défaut ou un bug?
Cycle de vie de la gestion des défauts
Lorsqu'un système donne une sortie différente autre que l'exigence commerciale réelle, c'est-à-dire lorsqu'il y a un écart par rapport à l'exigence commerciale réelle ou originale, nous pouvons dire qu'il y a un défaut dans le système / logiciel.
Lorsque l'équipe de test exécute les cas de test, elle rencontre une situation où le résultat réel du test est différent du résultat attendu. Cette variation est appelée Défaut .
Fondamentalement, un défaut logiciel est une condition qui ne répond pas aux exigences logicielles. Le défaut est une erreur ou un défaut qui produit un comportement inattendu ou incorrect dans le système.
Afin de gérer les projets de manière appropriée, vous devez savoir comment gérer le développement et la publication, mais avec cela, vous devez également savoir comment gérer les défauts.
Imaginez, que se passera-t-il si l'équipe de test signale les défauts verbalement et que l'équipe de développement met également à jour le statut du défaut verbalement? Le processus sera plus compliqué car ces défauts incluent tous les défauts comme réellement corrigés et fonctionnant comme prévu, corrigés mais toujours pas fonctionnels, rejetés, reportés et le processus continue.
Dans le cas ci-dessus, à mesure que le nombre de défauts augmente et que la communication se fait verbalement, la situation sera bientôt très pire. Afin de contrôler et de traiter efficacement le défaut, vous avez besoin d'un cycle de vie approprié.
Le cycle de vie des défauts garantit que le processus est uniforme et standardisé. Un défaut atteint différents états dans le cycle de vie. Une fois qu'un défaut a été trouvé, il passe par différentes étapes au cours de sa durée de vie et il est communément appelé Cycle de vie des défauts .
En règle générale, le cycle de vie d'un défaut commence à partir de l'étape où le défaut est détecté ou signalé par l'équipe de test et se termine lorsqu'un défaut est résolu en s'assurant qu'il n'est pas reproductible ou rejeté par une équipe de développement. Le nombre d'états traversés par un défaut varie d'un projet à l'autre.
Lectures complémentaires:
Noter: Le cycle inférieur diffère légèrement d'une organisation à l'autre.
Le cycle de vie des défauts ci-dessous couvre tous les états possibles:
- Chaque fois que l'équipe de test découvre un défaut dans l'application, elle le signale avec le statut ' NOUVEAU ».
- Lorsqu'un nouveau défaut est examiné par un responsable du contrôle qualité et si le défaut est valide, l'état du défaut serait ' Ouvert »Et il est prêt à être affecté à l'équipe de développement.
- Lorsqu'un responsable QA attribue le défaut au développeur correspondant, le statut du défaut est marqué comme ' Attribué ». Un développeur doit commencer à analyser et à corriger le défaut à ce stade.
- Lorsque le développeur estime que le défaut n'est pas authentique ou valide, le développeur rejette le défaut. L'état du défaut est marqué comme ' Rejeté »Et réaffecté à l'équipe de test.
- Si le défaut enregistré est répété deux fois ou si les deux défauts signalés ont des résultats et des étapes similaires à reproduire, alors un statut de défaut est changé en ' Dupliquer ».
- S'il y a des problèmes ou des obstacles dans la version actuelle pour corriger un défaut particulier, alors le défaut sera repris dans les versions à venir au lieu de la version actuelle, puis il est marqué comme ' Différé ' ou ' Reporté ».
- Lorsqu'un développeur n'est pas en mesure de reproduire le défaut en suivant les étapes mentionnées dans «Étapes à suivre pour reproduire» par l'équipe de test, le développeur peut marquer le défaut comme ' Non reproduisible' . À ce stade, l'équipe de test doit fournir des étapes de reproduction détaillées à un développeur.
- Si le développeur n'est pas clair sur les étapes à reproduire fournies par un AQ pour reproduire le défaut, il peut le marquer comme ' Besoin de plus d'informations ». Dans ce cas, l'équipe de test doit fournir les détails requis à l'équipe de développement.
- Si un défaut est déjà connu et actuellement présent dans l'environnement de production, le défaut est marqué comme ' Défaut connu ».
- Lorsqu'un développeur apporte les modifications nécessaires, le défaut est marqué comme ' Fixé ».
- Le développeur transmet maintenant le défaut à l'équipe de test pour vérification. Le développeur change donc le statut comme ' Prêt pour un nouveau test ».
- Si le défaut n'a plus de problèmes et qu'il est correctement vérifié, le testeur marque le défaut comme ' Fermé ».
- Lors du nouveau test du défaut, si le testeur a constaté que le défaut est toujours reproductible ou partiellement corrigé, le défaut serait marqué comme ' Rouvert ». Le développeur doit maintenant examiner à nouveau ce défaut.
Un cycle de vie des défauts bien planifié et contrôlé donne le nombre total de défauts détectés dans une version ou dans toutes les versions. Ce processus standardisé donne une image claire de la manière dont le code a été écrit, de la manière dont les tests ont été correctement effectués, de la manière dont le défaut ou le logiciel a été publié, etc. Cela réduira le nombre de défauts de production en trouvant les défauts lors des tests phase elle-même.
Processus de gestion des défauts
Le processus de gestion des défauts est expliqué ci-dessous en détail.
# 1) Prévention des défauts:
Prévention des défauts est la meilleure méthode pour éliminer les défauts au stade précoce des tests au lieu de rechercher les défauts au stade ultérieur et de les corriger. Cette méthode est également rentable car le coût requis pour réparer les défauts trouvés dans les premières étapes des tests est très faible.
Cependant, il n'est pas possible de supprimer tous les défauts, mais au moins vous pouvez minimiser l'impact du défaut et le coût de réparation.
Les principales étapes de la prévention des défauts sont les suivantes:
- Identifier les risques critiques : Identifiez les risques critiques dans le système qui auront plus d'impact s'ils se produisent pendant les tests ou à un stade ultérieur.
- Estimer l'impact attendu : Pour chaque risque critique, calculez quel serait l'impact financier si le risque était réellement rencontré.
- Minimiser l'impact attendu : Une fois que vous avez identifié tous les risques critiques, prenez les risques les plus élevés qui peuvent nuire au système s'ils sont rencontrés et essayez de minimiser ou d'éliminer le risque. Pour les risques qui ne peuvent être éliminés, il réduit la probabilité d'occurrence et son impact financier.
# 2) Base de référence livrable:
Lorsqu'un livrable (système, produit ou document) atteint son jalon prédéfini, vous pouvez dire qu'un livrable est une référence. Dans ce processus, le produit ou le livrable passe d'une étape à une autre et à mesure que le livrable passe d'une étape à une autre, les défauts existants dans le système sont également reportés à l'étape ou à l'étape suivante.
Par exemple, envisager un scénario de codage, de tests unitaires, puis de tests système. Si un développeur effectue un codage et des tests unitaires, les tests du système sont effectués par l'équipe de test. Ici, le codage et les tests unitaires sont une étape importante et les tests système en sont une autre.
Ainsi, pendant les tests unitaires, si le développeur trouve des problèmes, cela n'est pas appelé comme un défaut car ces problèmes sont identifiés avant le respect de la date limite. Une fois le codage et les tests unitaires terminés, le développeur remet le code pour le test du système et vous pouvez dire que le code est 'En ligne de base' et prêt pour la prochaine étape, ici, dans ce cas, il s'agit du «test du système».
Désormais, si les problèmes sont identifiés pendant les tests, ils sont appelés comme le défaut car ils sont identifiés après l'achèvement de l'étape précédente, c'est-à-dire le codage et les tests unitaires.
Fondamentalement, les produits livrables sont fondés lorsque les changements dans les produits livrables sont finalisés et que tous les défauts possibles sont identifiés et corrigés. Ensuite, le même livrable est transmis au groupe suivant qui y travaillera.
# 3) Découverte des défauts:
Il est presque impossible d'éliminer tous les défauts du système et d'en faire un système sans défaut. Mais vous pouvez identifier les défauts tôt avant qu'ils ne deviennent plus coûteux pour le projet. On peut dire que le défaut découvert signifie qu'il est formellement porté à l'attention de l'équipe de développement et après analyse, l'équipe de développement du défaut l'a également accepté comme un défaut.
quel est le meilleur pare-feu gratuit
Les étapes impliquées dans la détection des défauts sont les suivantes:
- Trouver un défaut : Identifiez les défauts avant qu'ils ne deviennent un problème majeur pour le système.
- Signaler un défaut : Dès que l'équipe de test trouve un défaut, sa responsabilité est de faire prendre conscience à l'équipe de développement qu'il y a un problème identifié qui doit être analysé et corrigé.
- Reconnaître le défaut : Une fois que l'équipe de test a attribué le défaut à l'équipe de développement, il incombe à l'équipe de développement de reconnaître le défaut et de continuer à le réparer s'il s'agit d'un défaut valide.
# 4) Résolution des défauts:
Dans le processus ci-dessus, l'équipe de test a identifié le défaut et signalé à l'équipe de développement. Maintenant, ici, l'équipe de développement doit procéder à la résolution du défaut.
Les étapes impliquées dans la résolution des défauts sont les suivantes:
- Hiérarchisez le risque : L'équipe de développement analyse le défaut et priorise la correction du défaut. Si un défaut a plus d'impact sur le système, ils font de la correction du défaut une priorité élevée.
- Réparer le défaut : En fonction de la priorité, l'équipe de développement corrige le défaut, les défauts de priorité plus élevée sont résolus en premier et les défauts de priorité inférieure sont corrigés à la fin.
- Signaler la résolution : Il est de la responsabilité de l’équipe de développement de s’assurer que l’équipe de test est au courant du moment où les défauts sont corrigés et de la manière dont le défaut a été corrigé, par exemple en modifiant l’un des fichiers de configuration ou en apportant des modifications au code. Cela aidera l'équipe de test à comprendre la cause du défaut.
# 5) Amélioration des processus:
Bien que dans le processus de résolution des défauts, les défauts soient classés par ordre de priorité et corrigés, du point de vue du processus, cela ne signifie pas que les défauts de priorité inférieure ne sont pas importants et n'affectent pas beaucoup le système. Du point de vue de l'amélioration des processus, tous les défauts identifiés sont identiques à un défaut critique.
Même ces défauts mineurs donnent l'occasion d'apprendre comment améliorer le processus et empêcher l'apparition de tout défaut susceptible d'avoir un impact sur une défaillance du système à l'avenir. L'identification d'un défaut ayant un impact moindre sur le système peut ne pas être un gros problème, mais les occurrences d'un tel défaut dans le système lui-même sont un gros problème.
Pour améliorer les processus, tout le monde dans le projet doit regarder en arrière et vérifier d'où provient le défaut. Sur cette base, vous pouvez apporter des modifications au processus de validation, au document de base, au processus de révision qui peuvent détecter les défauts au début du processus qui sont moins coûteux.
Conclusion
Le processus de gestion des défauts doit être suivi pendant tout le processus de développement logiciel et pas seulement pour des activités de test ou de développement spécifiques.
Si un défaut est détecté lors de la phase de test, une question peut être soulevée: si le défaut est détecté dans cette phase, qu'en est-il des autres défauts vivants dans le système qui peuvent provoquer une défaillance du système s'il se produit et n'est pas encore découvert.
Ainsi, tous les processus tels que le processus d'examen, les tests statiques, l'inspection, etc., doivent être renforcés et tout le monde dans le projet doit être sérieux au sujet du processus et contribuer si nécessaire. La haute direction de l'organisation doit également comprendre et soutenir le processus de gestion des défauts.
Les approches de test, le processus d'examen, etc. doivent être choisis en fonction de l'objectif du projet ou du processus organisationnel.
J'espère que cet article informatif sur le processus de gestion des défauts vous sera d'une immense aide.
lecture recommandée
- Qu'est-ce que la technique de test basée sur les défauts?
- Processus de triage des anomalies et moyens de gérer la réunion de triage des anomalies
- 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
- Tutoriel Bugzilla: Tutoriel pratique de l'outil de gestion des défauts
- Méthodes et techniques de prévention des défauts
- Didacticiel sur l'outil de gestion des défauts d'IBM Rational Team Concert
- Comment reproduire un défaut non reproductible et faire en sorte que votre effort de test en vaille la peine
- Les tests logiciels sont une question d'idées (et comment les générer)