bugs logiciels

8 bonnes pratiques pour gérer les bogues logiciels

**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.

 

Types de bogues

Bonnes pratiques pour gérer les bogues.

  1. SUIVRE LES BOGUES SUR VOTRE BACKLOG
  2. DESCRIPTION APPROPRIÉE DU BUGUE
  3. DÉFINIR LA PRIORITÉ
  4. DÉFINIR LA GRAVITÉ
  5. UTILISEZ DES MODÈLES AUSSI SOUVENT QUE POSSIBLE
  6. UTILISER LA SECTION DE DISCUSSION
  7. AUTOMATISER LA RÉAFFECTATION EN FONCTION DU CHANGEMENT D’ÉTAT
  8. NE JAMAIS PERDRE DE VUE
bogues logiciels

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 : 

  1. Allez sur la page de connexion
  2. Entrez le login correct
  3. Entrez le mot de passe correct
  4. 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.

Wersja polska
English version

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.

Posts created 110

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles similaires

Commencez à saisir votre recherche ci-dessus et pressez Entrée pour rechercher. ESC pour annuler.

Retour en haut