Utilisation des bogues

Lorsque vous exécutez des tests pour vérifier vos spécifications, vous pouvez être amené à rencontrer des bogues. Utilisez l'élément de travail Bogue pour décrire et suivre la progression de chaque bogue que vous trouvez. Pour plus d'informations sur la création d'éléments de travail Bogue, consultez Envoi de bogues. Lorsque des bogues sont trouvés, suivez le processus de cette rubrique pour les classer en fonction de leur priorité, vous assurer qu'ils sont résolus et vérifier que vous disposez d'un enregistrement du travail et des décisions impliqués.

Le formulaire d'élément de travail d'un bogue stocke des données dans les champs et onglets indiqués dans l'illustration suivante :

Dans cette rubrique

• Trier des bogues

• Résoudre un bogue

• Fermer un bogue

Trier des bogues

Des réunions de triage doivent être organisées à des intervalles définis après le début du travail de développement et des test du projet. La fréquence et la durée de ces réunions dépendent de votre situation.

En général, les réunions de triage de bogues sont dirigées par un chef de projet. Les participants sont les responsables d'équipe et dans certains cas des analystes d'entreprise et des parties prenantes qui peuvent s'exprimer au sujet des risques spécifiques du projet. Le chef de projet peut utiliser la requête Bogues actifs pour les bogues nouveaux et rouverts afin de générer une liste de bogues à trier.

Avant le début du triage, déterminez un ensemble de critères afin de déterminer les bogues qui doivent être résolus et selon quelle priorité. Les critères identifient généralement la gravité des bogues, les bogues associés à des fonctionnalités de valeur significative (ou avec un coût significatif en cas de retard) ou d'autres risques du projet.

Les critères de triage doivent être stockés dans le dossier Documents de votre projet d'équipe. Le document est mis à jour au fil du temps. Il est supposé que votre projet utilise le contrôle de version et que les critères spécifiques utilisés à un moment donné sur le projet peuvent être extraits dans des objectifs d'audit et de preuve d'évaluation.

Au début du projet, vous êtes susceptible de décider de résoudre la plupart des bogues que vous triez. Cependant, à mesure que le projet avance, les critères (ou la barre) de triage peuvent être élevés de façon à réduire le nombre des bogues résolus.

L'élévation de la barre de critères de triage et la possibilité de ne pas résoudre les bogues signalés est un compromis. Ce compromis stipule que la résolution du bogue est moins importante que le respect de la portée, du budget et de la planification du projet.

Utilisez vos critères pour déterminer les bogues à résoudre et comment définir leurs champs État, Priorité, Gravité et autres. Par défaut, le modèle fournit quatre priorités : de 1, pour les bogues « à résoudre », à 4, pour les bogues « sans importance ». Si vous modifiez les définitions contenues dans le modèle de processus, vous devez mettre à jour le guide, le texte d'aide et les documents de critères en conséquence.

Pour plus d'informations sur la façon de remplir l'élément de travail Bogue, consultez Bogue (CMMI).

Résoudre des bogues

Après avoir passé le triage et été classés par ordre de priorité, les bogues doivent être assignés à un développeur pour un examen supplémentaire.

L'élément de travail Bogue possède un onglet pour les étapes de reproduction, qui fournit les élément dont vous avez besoin pour reproduire le bogue. Toutefois, vous pouvez également utiliser IntelliTrace pour faciliter la reproduction des bogues difficiles. Pour plus d'informations sur IntelliTrace, consultez Inclusion de données de trace de diagnostic dans des bogues difficiles à reproduire et Débogage avec IntelliTrace.

Après avoir choisi une action, le développeur doit noter ses décisions dans l'élément de travail Bogue.

Choisir le correctif

Avec d'autres membres de l'équipe, le développeur peut recommander un correctif qui a des implications sur d'autres sections du code et qui peut nécessiter d'importants tests de régression. Toutes les conversations relatives à l'évaluation des risques d'un tel correctif doivent être enregistrées dans l'historique de l'élément de travail Bogue car elles constituent une preuve d'analyse de décision et de gestion des risques utile pour un audit ou une évaluation SCAMPI (méthode d'évaluation CMMI standard pour l'amélioration des processus). Pour plus d'informations concernant CMMI, consultez Informations générales sur CMMI.

Mettre à jour et exécuter des tests unitaires pour la résolution de bogues

Les tests unitaires vérifient l'implémentation correcte d'une unité de code. La rédaction et l'exécution de tests unitaires identifient les bogues avant le début des tests et, par conséquent, aident à réduire le coût du contrôle qualité. Les développeurs doivent écrire des tests unitaires pour tout le code impliqué dans l'implémentation d'une tâche de développement ou d'une résolution de bogue. Pour plus d'informations, consultez Vérification du code à l'aide de tests unitaires.

Vous pouvez préférer écrire le test unitaire avant de faire des correctifs de code dans une stratégie de développement donnant la priorité aux tests. Ce type de stratégie est favorisé par les développeurs de logiciels agiles. Le modèle CMMI n'exige pas que les tests unitaires soient écrits dans un ordre spécifique, uniquement qu'une vérification efficace des fonctionnalités soit réalisée.

La preuve que des tests unitaires ont été à la fois rédigés et exécutés est requise pour une évaluation CMMI. Veillez à lier les tests aux éléments de travail Tâche pour le correctif de code et liez ces tâches à l'élément de travail Bogue. Vous générez ainsi la traçabilité de la preuve qu'un expert SCAMPI voudra consulter.

Réviser et refactoriser le code pour la résolution de bogues

Une révision du code permet de vérifier que le code nouveau ou modifié atteint un seuil de qualité établi avant l'intégration du code dans la build quotidienne. Les considérations de qualité sont les normes de codage, la conformité à l'architecture et à la conception, les performances, la lisibilité et la sécurité. Les révisions du code fournissent également un éclairage supplémentaire de la part d'autres développeurs à propos de la façon dont le code doit être écrit. Pour plus d'informations sur la révision et la refactorisation du code, consultez Implémentation des tâches de développement.

Fermer les bogues

Une fois un bogue résolu, il doit être assigné à un testeur qui vérifie que le problème a bien été résolu avant que l'élément de travail Bogue ne soit fermé.

Vérification d'un correctif

Pour vérifier un correctif, le testeur doit essayer de reproduire le bogue, rechercher le comportement inattendu supplémentaire, et, si nécessaire, réactiver le bogue.

Lorsque vous vérifiez une résolution de bogue, vous pouvez penser que le bogue n'a pas été entièrement résolu ou vous pouvez être en désaccord avec la résolution proposée. Dans ce cas, vous discutez du bogue avec la personne qui l'a résolu, vous vous mettez d'accord, et, le cas échéant, vous réactivez le bogue. Si vous réactivez un bogue, veillez à indiquer les raisons de cette réactivation dans la description du bogue afin que les informations soient conservées.

Fermeture de l'élément de travail Bogue

De nombreuses raisons peuvent être à l'origine de la fermeture d'un bogue. Dans un cas simple, la résolution d'un bogue a été vérifiée et celui-ci peut être fermé. Toutefois, un bogue peut être différé jusqu'à la version suivante du produit, s'il est prouvé qu'il n'est pas reproductible ou qu'il s'agit d'un doublon. Chacune de ces raisons doit être documentée, et le bogue doit être fermé correctement de façon à ce qu'il n'existe aucune confusion à propos de sa fermeture.

Voir aussi

Concepts

Envoi de bogues

Débogage avec IntelliTrace

Autres ressources

Inclusion de données de trace de diagnostic dans des bogues difficiles à reproduire