**Ce texte en version anglaise est publié sur www.softwarehut.com **
Bonnes pratiques pour gérer les bogues logicielss. En 1947, la programmeuse Grace Hopper a constaté un dysfonctionnement de l’ordinateur Mark II, causé par une mite trouvée dans les composants électromécaniques. Hopper et les membres de son équipe ont commencé à utiliser le terme « bug » pour décrire les dysfonctionnements des ordinateurs. Dans les années 1940, il n’y avait qu’une poignée de ces appareils dans le monde et l’informatique et la programmation en étaient à leurs débuts. Le terme « bouges » a donc été popularisé pour décrire tout comportement informatique inattendu et il est entré dans le jargon de la programmation.
Bonnes pratiques pour gérer les bogues.
- SUIVRE LES BOGUES SUR VOTRE BACKLOG
- DESCRIPTION APPROPRIÉE DU BUGUE
- DÉFINIR LA PRIORITÉ
- DÉFINIR LA GRAVITÉ
- UTILISEZ DES MODÈLES AUSSI SOUVENT QUE POSSIBLE
- UTILISER LA SECTION DE DISCUSSION
- AUTOMATISER LA RÉAFFECTATION EN FONCTION DU CHANGEMENT D’ÉTAT
- NE JAMAIS PERDRE DE VUE
Types de bogues
L’expérience de différents types d’erreurs en programmation constitue une part importante du processus de développement. Les meilleurs développeurs deviennent à l’aise avec les bogues logiciels qu’ils créent et les corrigent rapidement. Les origines de ces bogues sont diverses :
Les plus faciles à corriger sont les défauts des programmeurs résultant du manque de connaissances ou d’expérience d’un programmeur particulier, de sa précipitation ou d’un manque d’attention.
Les situations imprévues, telles qu’un fonctionnement inattendu du matériel, une séquence imprévue d’événements utilisateur (par exemple, la sélection d’options à l’écran dans un ordre différent de celui prévu), ou une combinaison des deux, sont généralement plus difficiles à corriger.
Les erreurs résultant d’exigences défectueuses, imprécises ou contradictoires sont les plus difficiles à corriger. Elles nécessitent une nouvelle analyse des exigences, leur correction, ainsi qu’une nouvelle conception, une nouvelle mise en œuvre et un nouveau test. Ce sont les bogues les plus coûteux.
Dans les deux premiers cas, avant que le développeur puisse corriger le bogue avec succès, il doit d’abord identifier la cause et répéter la séquence d’événements qui a conduit au bogue. Il est donc important de documenter minutieusement le rapport de bug ou de défaut.
Bonnes pratiques pour la gestion des bogues logiciels
Si vous écrivez des logiciels, vous rencontrerez sans doute quelques bogues en cours de route. Voici quelques conseils rapides sur la façon de gérer et de suivre efficacement ces bogues logiciels.
SUIVEZ LES BOGUES LOGICIELS DANS VOTRE CARNET DE COMMANDES
En tant que chef de projet, je peux choisir avec mon équipe la manière dont nous voulons gérer les bogues logiciels. Certaines équipes préfèrent suivre les bogues avec les exigences. D’autres équipes décident de suivre les bugs en tant que tâches réalisées pour répondre à une exigence.
DESCRIPTION APPROPRIÉE DES BOGUES LOGICIELS
Une description appropriée des bugs nous permet de capturer à la fois le problème initial et les découvertes faites lors du triage, de l’investigation, de la correction et de la fermeture du bogues. C’est pourquoi nous disposons d’un modèle général pour ce type d’élément de travail. Nous distinguons les points principaux, passons-les en revue :
Titre
Le titre fait le plus souvent référence à l’environnement où nous trouvons le défaut et au rôle d’un utilisateur testeur. Ensuite, nous décrivons le type de bug. Voir l’exemple ci-dessous :
[environnement] – [rôle] – description du bug/de la bande
[ dev | uat | prod] – [admin | user | manager] – ne peut pas se connecter à l’application
Étapes de la reproduction
Nous entrons ici une description compréhensible qui nous permet de saisir suffisamment d’informations pour comprendre l’impact complet du problème. Cela inclut les actions entreprises pour trouver ou reproduire le bogue et son comportement attendu.
Tout d’abord, nous décrivons les étapes pour reproduire le bug (souvent en l’appuyant avec des captures d’écran ou des enregistrements). Voyons l’exemple :
Situation actuelle :
Lorsque vous essayez de vous connecter à l’application avec un compte administrateur, le bouton de connexion n’effectue aucune action.
Étapes à reproduire :
- Allez sur la page de connexion
- Entrez le login correct
- Entrez le mot de passe correct
- Cliquer sur le bouton Login
Ensuite, nous décrivons les critères que l’équipe doit utiliser pour vérifier si le défaut du code est corrigé. Cela nous permet d’évaluer efficacement si un élément a été réalisé de manière satisfaisante.
Comportement attendu :
Une fois que les détails corrects ont été saisis, l’administrateur devrait être en mesure de se connecter à l’application.
Informations sur le système
Informations sur le logiciel et la configuration du système tel que nous :
Branche affectée :
Build affecté : Chaque déploiement fait passer la version de construction de 0.1.0 à 0.1.1, 0.1.2, etc.
Ainsi, lorsque vous rapportez un bug, le numéro de build doit être ajouté.
Système d’exploitation : Windows XP, Windows 7, Windows 8, Windows 10, Android, IOS, MacOS
Navigateur : Google Chrome, Mozilla Firefox, Opera Web Browser, Safari Web Browser, Internet Explorer
DÉFINIR LA PRIORITÉ
La priorité est une évaluation subjective, et elle est liée à l’activité. Elle indique l’ordre dans lequel les défauts du code doivent être corrigés. Nous spécifions les valeurs suivantes :
1 – Le produit ne peut pas être expédié sans cela, faites-le dès que possible.
2 – Le produit ne peut pas être expédié sans ce travail, mais il n’est pas nécessaire de le faire immédiatement.
3 – L’élément de travail est facultatif en fonction des ressources, du temps et du risque.
4 – L’élément de travail n’est pas nécessaire.
DÉFINIR LA GRAVITÉ
La gravité est une évaluation subjective de l’impact d’un bogue sur le projet. Nous spécifions les valeurs suivantes :
1 – Critique. Doit être corrigé. Un défaut qui provoque une corruption importante des données ou qui a un impact sur un ou plusieurs composants du système. Il n’existe pas de méthodes alternatives acceptables pour obtenir les résultats requis.
2 – Élevé. Envisagez de le corriger. Défaut qui entraîne une corruption importante des données ou qui a un impact sur un ou plusieurs composants du système. Cependant, il existe une méthode alternative acceptable.
3 – Moyenne. Défaut qui fait que le système produit des résultats incorrects, incomplets ou incohérents.
4 – Faible. Un défaut mineur ou cosmétique. Des solutions de rechange acceptables existent pour obtenir les résultats requis.
Le membre de l’équipe d’acceptation de la qualité qui connaît les exigences du client peut facilement déterminer la gravité.
UTILISEZ DES MODÈLES AUSSI SOUVENT QUE POSSIBLE
Les modèles d’éléments de bogue sont utiles. Les modèles soutiennent des objectifs tels que :
Créer des bogues pour des domaines de produits spécifiques.
Fournir des conseils pour remplir l’élément de travail
Définir des normes
Créer des éléments de travail avec des balises spécifiques
Comme nous pouvons créer rapidement des éléments de travail dont les valeurs sont préremplies, nous gagnons du temps.
UTILISER LA SECTION DE DISCUSSION
Nous utilisons la section de discussion de l’outil de gestion Azure DevOps pour ajouter et examiner les commentaires faits sur le travail effectué. Naturellement, nous discutons des tâches en détail, à mesure que le travail progresse. Des commentaires appropriés sous les tâches clarifient les doutes et facilitent le travail des testeurs.
AUTOMATISER LA RÉAFFECTATION EN FONCTION DU CHANGEMENT D’ÉTAT
Azure DevOps Boards nous permet de configurer une règle qui réassigne le bug à la personne qui l’a créé dès que l’état de l’élément de travail passe à Résolu. Cette règle est facultative, mais fortement recommandée – elle facilite la gestion et accélère la volonté de tester.
NE JAMAIS PERDRE DE VUE
Les défauts sont délicats. Parfois, les corrections de bogues impliquent plus d’une seule section de code. Cela nécessite des tests de régression. Nous enregistrons donc tous les symptômes et évaluons le risque de bogues. Certaines analyses relatives aux bugs actifs par priorité, aux bugs en cours, aux bugs à corriger pour une version cible ou surtout aux bugs récents, sont fortement recommandées.
Les bugs sont inévitables
Les bogues logiciels ont des origines diverses, allant des défauts du programmeur aux erreurs découlant des exigences, en passant par les situations imprévues. Il convient de souligner qu’il est normal qu’ils soient présents.
Cependant, le nombre d’erreurs dans les logiciels est en corrélation avec la qualité largement comprise des logiciels. En tant que gestionnaires de projet, nous soutenons cette qualité par de bonnes pratiques de gestion de projet.
Chère lectrice / cher lecteur, le français n’est pas ma langue maternelle, mais je vais faire de mon mieux ici. Merci pour votre aide à l’amélioration de la traduction.
