Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez aussi afficher la version anglaise dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte.
Traduction
Anglais

Tableau de bord Qualité (Agile et CMMI)

 

Vous pouvez utiliser le tableau de bord Qualité pour obtenir une vue d'ensemble de la progression des processus de test, de développement et de génération étant donné qu'ils sont en rapport avec la qualité du logiciel en cours de développement. L'équipe peut employer le tableau de bord Qualité pour identifier et prendre des décisions soutenant les objectifs qu'elle a définis concernant la qualité du produit.

En utilisant ce tableau de bord, vous pouvez examiner l'avancement des tests, l'état des builds, les progrès réalisés dans le domaine de la résolution et de la fermeture des bogues, le taux de réactivation des bogues, le pourcentage de code testé et les tendances relatives aux modifications du code. Chacune de ces métriques est tracée pour les quatre dernières semaines.

Dans cette rubrique

Vous pouvez utiliser ce tableau de bord pour répondre aux questions suivantes :

  • L'effort de test progresse-t-il ?

  • L'équipe teste-t-elle la fonctionnalité appropriée ?

  • La qualité des résolutions de bogue de l'équipe est-elle optimale ?

  • Les tests sont-ils périmés ?

  • L'équipe a-t-elle suffisamment de tests ?

  • Existe-t-il des goulots d'étranglement ?

Spécifications

Mêmes spécifications définies dans Tableaux de bord de portail de projet.

Les membres de l'équipe peuvent utiliser le tableau de bord Qualité pour déterminer la qualité globale du produit qu'ils développent. Idéalement, les taux de réussite des tests, les bogues et l'évolution du code reflètent tous la même situation ; toutefois, tel est rarement le cas. Lorsque vous identifiez une différence, vous devez examiner très attentivement la build et la série de données appropriées. Le tableau de bord Qualité combine les résultats des tests, la couverture du code par les tests, l'évolution du code et les bogues pour vous aider à cerner simultanément de nombreuses perspectives.

Pour en savoir plus sur les composants WebPart qui sont affichés dans le tableau de bord Qualité, consultez l'illustration et le tableau suivants.

Tableau de bord Qualité de produit
System_CAPS_noteRemarque

Le rapport Progression du plan de test est disponible uniquement quand l'équipe crée des plans de test et exécute des tests.

Les graphiques de progression, de build et de code, ainsi que les rapports Étape 1 à Étape 6, ne s'affichent pas quand l'entrepôt de données du projet d'équipe n'est pas disponible.

Pour en savoir plus sur l'interprétation, la mise à jour ou la personnalisation des graphiques qui s'affichent dans le tableau de bord Qualité, consultez les rubriques du tableau suivant.

Composant WebPart

Données affichées

Rubrique connexe

Étape 1

Graphique en aires empilées des résultats de tests de tous les cas de test regroupés selon le résultat enregistré le plus récent, Jamais exécuté, Bloqué, Échec ou Réussite, au cours des quatre dernières semaines.

Rapport Excel Progression du plan de test

Progression du plan de test, rapport

Étape 2

Histogramme empilé qui affiche le nombre de builds dans l'état Échec ou Opération réussie au cours des quatre dernières semaines.

Rapport État de la build

État de la build, rapport Excel

Étape 3

Graphique en aires empilées du nombre cumulé de bogues, regroupés par état, au cours des quatre dernières semaines.

Rapport Excel Progression des bogues

Progression des bogues, rapport Excel

Étape 4

Graphique en aires empilées du nombre de bogues réactivés par l'équipe à partir de l'état Résolu ou Fermé au cours des quatre dernières semaines.

Rapport Excel Réactivations des bogues

Réactivations des bogues, rapport Excel

Étape 5

Graphique en courbes qui indique le pourcentage de code testé par les tests de vérification de build (BVT) et d'autres tests au cours des quatre dernières semaines.

Rapport Couverture du code

Couverture du code, rapport Excel

Étape 6

Graphique en aires empilées qui indique le nombre de lignes de code que l'équipe a ajoutées, supprimées et modifiées dans les archivages précédant la build au cours des quatre dernières semaines.

Rapport Évolution du code

Évolution du code, rapport Excel

Étape 7

Liste des événements à venir. Cette liste est dérivée d'un composant WebPart SharePoint.

Importer le WebPart Événements

Non applicable

Étape 8

Nombre d'éléments de travail actifs, résolus et fermés. Vous pouvez ouvrir la liste d'éléments de travail en choisissant chaque nombre. Cette liste est issue d'un composant WebPart Team Web Access.

WebPart Éléments de travail du projet

Non applicable

9

Liste des builds récentes et leur état. Vous pouvez afficher davantage de détails en sélectionnant une build spécifique. Cette liste est issue d'un composant WebPart Team Web Access.

WebPart Builds récentes

Légende :

Build en cours de génération : la génération n'a pas démarré

Build non démarrée : la génération est en cours

Build réussie : la génération a réussi

Échec de la build : la génération a échoué

Build arrêtée : la génération est arrêtée

Build partiellement réussie : Build partiellement réussie

Exécuter, surveiller et gérer des builds

10

Liste des archivages les plus récents. Vous pouvez afficher davantage de détails en sélectionnant un archivage spécifique. Cette liste est issue d'un composant WebPart Team Web Access.

WebPart Archivages récents

Développer du code et gérer des modifications en attente

Pour que le tableau de bord Qualité fournissent des informations utiles et précises, l'équipe doit mettre en œuvre les activités décrites dans cette section.

Pour que le rapport Progression du plan de test soit utile et précis, l'équipe doit effectuer les activités suivantes :

  • Définir les cas de test et les récits utilisateur, et créer les liens Testé par entre les cas de test et les récits utilisateur.

  • Définir des plans de test et leur assigner des cas de test.

  • Pour les tests manuels, marquer les résultats de chaque étape de validation dans le cas de test comme ayant réussi ou échoué.

    System_CAPS_importantImportant

    Les testeurs doivent marquer une étape de test en précisant un état s'il s'agit d'une étape d'un test de validation. Le résultat total pour un cas de test reflète l'état de toutes les étapes de test marquées par le testeur. Par conséquent, l'état Échec sera affecté au cas de test si l'une des étapes de test a été marquée comme ayant échoué par le testeur ou n'a pas été marquée.

    Pour les tests automatisés, chaque cas de test est automatiquement marqué comme ayant réussi ou échoué.

  • (Facultatif) Pour prendre en charge le filtrage, assignez des chemins Itération et Zone à chaque cas de test.

    System_CAPS_noteRemarque

    Pour plus d'informations sur la façon de définir des chemins d'accès d'itération et de zone, consultez Procédure : création et modification de zones et d'itérations.

Pour que les rapports Progression des bogues et Réactivations des bogues soient utiles et précis, l'équipe doit effectuer les activités suivantes :

  • Définir des bogues.

  • Mettre à jour la valeur État de chaque bogue à mesure qu'il est résolu, vérifié, fermé ou réactivé par l'équipe.

  • (Facultatif) Spécifier les chemins Itération et Zone de chaque bogue si vous souhaitez effectuer un filtrage en fonction de ces champs.

Pour que les rapports État de la build, Couverture du code et Évolution du code soient utiles et précis, les membres de l'équipe doivent mettre en œuvre les activités suivantes :

  • Configurer un système de génération. Pour utiliser Team Foundation Build, vous devez installer un système de génération.

    Pour plus d'informations, consultez Configure and manage your build system.

  • Créer des définitions de build. Vous pouvez créer plusieurs définitions de build, puis exécuter chacune d'elle afin de produire le code pour une plateforme différente. De plus, vous pouvez exécuter chaque build pour une configuration différente.

    Pour plus d'informations, consultez Définir votre processus de build.

  • Définir des tests à exécuter automatiquement dans le cadre de la build : dans le cadre de la définition de build, vous pouvez définir des tests qui doivent s'exécuter avec la build, ou ne pas s'exécuter en cas d'échec de cette dernière.

    Pour plus d'informations, consultez Utiliser le modèle par défaut pour un processus de build.

  • Configurer des tests pour rassembler les données de couverture du code : pour que les données de couverture du code s'affichent dans le rapport, les membres de l'équipe doivent instrumenter des tests pour rassembler ces données.

    Pour plus d'informations, consultez Exécuter des tests dans votre processus de génération

  • Exécuter les builds régulièrement Vous pouvez exécuter les builds à des intervalles réguliers ou après chaque archivage. Vous pouvez créer des builds normales lorsque vous utilisez le déclencheur de planification.

    Pour plus d'informations, consultez Créer ou modifier une définition de build et Exécuter, surveiller et gérer des builds.

    System_CAPS_noteRemarque

    Même si un membre de l'équipe peut évaluer manuellement une build à l'aide de l'Explorateur de builds, cette évaluation n'est pas reportée dans le rapport Indicateurs de qualité de build. L'évaluation de la build s'affiche dans le rapport Résumé de la build. Pour plus d'informations, consultez Évaluer la qualité d'une build terminée et Résumé de la build, rapport.

Le tableau suivant décrit les problèmes de qualité spécifiques que le tableau de bord Qualité peut vous aider à analyser et identifie les mesures que l'équipe peut prendre.

Problème

Rapports à examiner

Remarques relatives à la résolution des problèmes

Les builds échouent

État des builds

Les builds nocturnes sont essentielles pour les projets de développement de logiciel. Lorsque les builds ne se terminent pas correctement ou ne réussissent pas les tests de vérification de build (BVT), l'équipe doit immédiatement résoudre le problème.

Les tests échouent

Progression du plan de test

Évolution du code

Lorsque les taux d'échec des tests et le degré d'évolution du code sont élevés, l'équipe peut chercher à savoir pourquoi les échecs du logiciel sont si fréquents. Des méthodes de développement insuffisamment structurées ou des tests trop rigoureux pour un premier cycle d'itération font partie des causes possibles.

Les tests réussissent, mais avec un taux élevé d'identification de bogues

Progression du plan de test

Progression des bogues

Si de nombreux tests réussissent et que de nombreux bogues sont identifiés sur une même période, l'équipe peut étudier les possibilités suivantes :

  • Les tests ne sont peut-être pas suffisamment rigoureux pour l'étape de développement actuelle du produit. Dans les premières itérations, il convient d'effectuer des tests simples. Toutefois, les tests doivent couvrir des scénarios et des intégrations plus larges à mesure que le produit arrive à maturité.

  • Les tests peuvent être périmés ou tester des fonctionnalités inappropriées.

  • D'autres techniques de test peuvent donner de meilleurs résultats.

  • Des bogues sont signalés, mais ne font pas l'objet de tests. Si des bogues sont signalés et ne sont liés à aucun cas de test, ils ne sont pas soumis aux tests de régression.

Les tests sont périmés

Progression du plan de test

Couverture du code

Évolution du code

Si de nombreux tests réussissent, qu'une quantité significative de code est modifiée et que la couverture du code diminue, cela peut signifier que les tests exécutés par l'équipe ne couvrent pas le nouveau code.

Étant donné que le développement des tests et les modifications du code ne s'effectuent pas au même rythme, la couverture de test peut devenir de moins en moins appropriée.

L'équipe ne procède pas au test, à la fermeture ou à la réactivation des bogues résolus

Progression des bogues

Lorsque le rapport Progression des bogues indique une augmentation soudaine des bogues résolus, cela signifie que les développeurs résolvent les bogues, mais que les testeurs ne les ont pas vérifiés ni fermés. L'équipe doit chercher à savoir pourquoi ce scénario s'est développé.

Nombre insuffisant de tests

Progression du plan de test

Évolution du code

Si l'équipe exécute peu de tests, que le degré d'évolution du code est élevé et que la couverture du code est inférieure aux attentes, cela peut signifier que l'équipe doit allouer davantage de ressources aux tests. En outre, l'équipe doit vérifier que les testeurs se concentrent sur les mêmes fonctions que le reste de l'équipe.

Réactivations

Réactivations des bogues

Si la fréquence de réactivation des bogues par l'équipe est élevée ou augmente, cela signifie que les testeurs rejettent fréquemment les résolutions des développeurs. L'équipe doit traiter ces problèmes pour éviter qu'une quantité importante de ressources ne soit chargée de retravailler les résolutions rejetées. Les causes potentielles incluent un signalement insuffisant des bogues, une gestion inefficace des laboratoires de test ou un triage trop agressif.

Tests unitaires inappropriés

Couverture du code

Évolution du code

Lorsqu'une diminution de la couverture du code coïncide avec une augmentation du degré d'évolution de ce dernier, cela peut signifier que les développeurs archivent le code sans que les tests unitaires correspondants soient exécutés pour le couvrir.

Dans la plupart des cas, le taux de couverture du code doit être proche de 100 % si l'équipe a recours au développement piloté par test ou à des techniques similaires. Si les tests unitaires sont réutilisés en tant que tests de vérification de build, la couverture du code doit être indiquée dans les rapports correspondants.

Afficher: