Tableau de bord Qualité (Agile et CMMI)

Article
09/28/2016

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

Données affichées dans le tableau de bord
Activités requises pour le suivi de la qualité
Résoudre les problèmes liés à la qualité

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.

Données affichées dans le tableau de bord

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

Notes

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
	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.	Progression du plan de test, rapport
	Histogramme empilé qui affiche le nombre de builds dans l'état Échec ou Opération réussie au cours des quatre dernières semaines.	État de la build, rapport Excel
	Graphique en aires empilées du nombre cumulé de bogues, regroupés par état, au cours des quatre dernières semaines.	Progression des bogues, rapport Excel
	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.	Réactivations des bogues, rapport Excel
	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.	Couverture du code, rapport Excel
	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.	Évolution du code, rapport Excel
	Liste des événements à venir. Cette liste est dérivée d'un composant WebPart SharePoint.	Non applicable
	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.	Non applicable
	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. Légende : : la génération n'a pas démarré : la génération est en cours : la génération a réussi : la génération a échoué : la génération est arrêtée : Build partiellement réussie	Exécuter, surveiller et gérer des builds
	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.	Développer du code et gérer des modifications en attente

Activités requises pour le contrôle de la qualité

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.

Activités requises pour le suivi de la progression du plan de test

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

Important

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.

Notes

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.

Activités requises pour le suivi de la progression des bogues et des réactivations de bogues

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.

Activités requises pour le suivi de l'état des builds, ainsi que de la couverture et de l'évolution du code

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.

Notes

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.

Résoudre les problèmes liés à la qualité

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.

Voir aussi

Tableaux de bord de portail de projet

Partager via