Partager via


Qualité, tableau de bord (Agile)

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.

[!REMARQUE]

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 ou 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

[!REMARQUE]

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 Microsoft Test Manager.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

É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, Ne jamais exécuter, 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 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 cliquant sur chaque nombre.Cette liste est dérivée d'un composant WebPart Team Web Access.

WebPart Éléments de travail du projet

Éléments de travail et workflow (Agile)

9

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.

WebPart Builds récentes

Légende :

Build en cours de génération: build en cours de génération

Build non démarrée: build non démarrée

Build réussie: build ayant réussi

Échec de la build: build ayant échoué

Build arrêtée: build arrêtée

Build partiellement réussie: build partiellement réussie

Managing and Reporting on Builds

10

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.

WebPart Archivages récents

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.

Dd420562.collapse_all(fr-fr,VS.110).gifActivité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 récits utilisateur, et créer des liens Testé par entre les cas de test et les récits utilisateur.

  • Définir des plans de test et assigner à ces derniers des cas de test.Pour plus d'informations, consultez Définition d'un plan 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.

    [!REMARQUE]

    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.

Dd420562.collapse_all(fr-fr,VS.110).gifActivité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.

Dd420562.collapse_all(fr-fr,VS.110).gifActivité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 :

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 :

Voir aussi

Concepts

Tableaux de bord (Agile)

Artefacts (Agile)

Autres ressources

Scrum