Qualité, tableau de bord (CMMI)

Article
08/15/2011

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.

Notes

Vous accédez aux tableaux de bord via votre portail du projet d'équipe. Vous pouvez accéder au tableau de bord Qualité uniquement si votre portail a été activé et configuré pour utiliser Microsoft Office SharePoint Server 2007. Pour plus d'informations, consultez Tableaux de bord (Agile) ou Accéder à un portail de projet d'équipe et au guide de processus.

Dans cette rubrique

Données qui s'affichent dans le tableau de bord
Activités requises pour le suivi de la qualité
Résolution des problèmes liés à la qualité
Personnalisation du tableau de bord 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 ?

Autorisations requises

Pour afficher le tableau de bord, vous devez appartenir ou être assigné à un groupe disposant de l'autorisation Lire dans les produits SharePoint pour le projet d'équipe. Pour modifier, copier ou personnaliser un tableau de bord, vous devez être assigné ou appartenir à un groupe disposant de l'autorisation Membres dans les produits SharePoint pour le projet d'équipe. Pour plus d'informations, consultez Ajouter des utilisateurs aux projets d'équipe.

Pour modifier un rapport dans Office Excel, vous devez être membre du rôle de sécurité TfsWarehouseDataReaders dans SQL Server Analysis Services et être assigné ou appartenir à un groupe disposant de l'autorisation Membres dans les produits SharePoint pour le projet d'équipe. Pour plus d'informations, consultez Accorder l'accès aux bases de données de l'entrepôt de données pour Visual Studio ALM.

Pour afficher un élément de travail, vous devez être membre du groupe Lecteurs ou l'autorisation Afficher les éléments de travail dans ce nœud doit avoir la valeur Autoriser. Pour créer ou modifier un élément de travail, vous devez être membre du groupe Contributors ou disposer de l'autorisation Modifier les éléments de travail dans ce nœud avec la valeur Autoriser. Pour plus d'informations, consultez Gestion des autorisations.

Données qui s'affichent 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.

En particulier, ce tableau de bord affiche les WebParts qui sont présentés dans l'illustration et le tableau suivants.

Tableau de bord Qualité de produit

Notes

Le rapport Progression du plan de test est disponible uniquement lorsque l'équipe crée des plans de test et exécute des tests à l'aide de Test Runner et Gestionnaire de tests Microsoft. Pour plus d'informations sur la définition de suites et de plans de test, consultez Organisation de cas de test à l'aide de suites de tests.

Les graphiques de progression, de build et de code, ainsi que les rapports Étape 1 à Étape 6 , ne s'affichent pas lorsque 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 tests regroupés selon le résultat enregistré le plus récent, Ne jamais exécuter, 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 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 cliquant sur chaque nombre. Cette liste est dérivée d'un composant WebPart Team Web Access.	Éléments de travail et flux de travail (CMMI)
	Liste des builds récentes et leur état. Vous pouvez afficher davantage de détails en cliquant sur une build spécifique. Cette liste est dérivée d'un composant WebPart Team Web Access. Légende : : build en cours de génération : build non démarrée : build ayant réussi : build ayant échoué : build arrêtée : build partiellement réussie	Gérer et afficher des builds terminées
	Liste des archivages les plus récents. Vous pouvez afficher davantage de détails en cliquant sur un archivage spécifique. Cette liste est dérivée d'un composant WebPart Team Web Access.	Utilisation des fenêtres Archiver et 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 des cas de test et des spécifications, et créer des liens Testé par entre les cas de test et les spécifications.
Définir des plans de test et assigner à ces derniers des cas de test. Pour plus d'informations, consultez Définition de votre effort de test à l'aide de plans 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 définition des chemins d'itération et de zone, consultez Créer et modifier des zones et des 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 Configurer votre système de génération.
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 Définir une build à l'aide du modèle par défaut.
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 Comment : configurer la couverture du code à l'aide de paramètres de test pour les tests automatisés et How to: Gather Code-Coverage Data with Generic Tests.
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 une définition de build de base et Exécuter et surveiller des builds.

Notes

Même si un membre de l'équipe peut évaluer manuellement une build à l'aide de l'Build Explorer, 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ésolution des 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.

Personnalisation du tableau de bord Qualité

Vous pouvez personnaliser le tableau de bord Qualité comme suit :

Modifiez les filtres de chaque rapport Excel pour vous concentrer sur des zones de produit ou des itérations spécifiques.
Ajoutez un composant WebPart de requête personnalisée qui affiche la liste des éléments de travail recherchés par la requête. Par exemple, vous pouvez ajouter une requête répertoriant tous les bogues actifs qui ne sont pas liés à un cas de test. Cette requête affichera le nombre de bogues signalés qui ne sont pas identifiés par des tests et ne font par conséquent pas l'objet de tests de régression.
Ajoutez au tableau de bord des rapports Excel existants, tels que Tendances des bogues et Analyse de l'échec.

Pour plus d'informations sur l'utilisation et la personnalisation des rapports dans Office Excel, consultez les pages suivantes sur le site Web Microsoft :