Tableau de bord Test (Agile et CMMI)

Article
09/28/2016

Grâce au tableau de bord de test, vous pouvez surveiller des activités des tests, créer des rapports sur la progression, rechercher des écarts dans la couverture de test et identifier des zones de test susceptibles de nécessiter un examen complémentaire. Ce tableau de bord contient cinq rapports qui fournissent des informations à propos des tests réalisés au cours des quatre dernières semaines.

Dans cette rubrique

Données affichées dans le tableau de bord
Activités requises pour surveiller les efforts de test
Surveiller la progression des tests
Déterminer des écarts de tests
Surveiller les échecs et régressions de tests

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

La création du cas de test est-elle sur les rails ?
L'équipe a-t-elle défini des cas de test pour la totalité des récits utilisateur ou des spécifications ?
Quelle est la proportion des cas de test qui réussissent, échouent et sont bloqués ?
Les mesures d'échec de test indiquent-elles un problème qui requiert un examen approfondi ?
Quel est l'état de la build exécutée hier soir ?
Quels sont les archivages les plus récents ?

Spécifications

Les rapports Progression du plan de test, Disponibilité du cas de test, État du test du récit utilisateur, État du test des spécifications et Activité de test sont disponibles uniquement quand l'équipe crée des plans de test et exécute les tests comme indiqué dans la section Planifier des tests manuels à l'aide de Team Web Access.
Les burndown charts, les graphiques de progression et les graphiques de tendances, ainsi que les rapports à , ne s'affichent pas quand le serveur qui héberge Analysis Services pour le projet d'équipe n'est pas disponible.
Les spécifications répertoriées dans Tableaux de bord de portail de projet sont également concernées.

Données affichées dans le tableau de bord

Vous pouvez utiliser le tableau de bord de test pour connaître la progression de l'équipe dans le cadre des tests des récits utilisateur (Agile) ou des spécifications (CMMI). Le tableau de bord de test affiche les composants WebPart suivants.

Version du modèle de processus Agile

WebParts pour le tableau de bord Progression des tests

Version du modèle de processus CMMI

Tableau de bord Test

Composant WebPart	Données affichées	Rubrique connexe
	Graphique en aires empilées des résultats de tous les cas de test regroupés selon le résultat enregistré le plus récent au cours des quatre dernières semaines. Les résultats peuvent être Jamais exécuté, Bloqué, Échec ou Réussite.	Progression du plan de test, rapport
	Graphique en aires empilées qui indique combien de cas de test ont possédé l'état Design ou Prêt au cours des quatre dernières semaines.	Disponibilité du cas de test, rapport
	Graphique à barres horizontales qui indique le nombre de résultats pour chaque combinaison de cas de test et configuration de test définie pour chaque récit utilisateur ou spécification. Le graphique regroupe les résultats des tests en fonction de leur série de tests la plus récente, avec les options Réussite (vert), Échec (rouge), Bloqué (violet) ou Pas exécuté (gris).	État du test du récit utilisateur, rapport Excel (Agile) État du test des spécifications, rapport Excel (CMMI)
	Graphique en courbes qui indique le nombre cumulé de tous les résultats exécutés pour tous les cas de test manuel au cours des quatre dernières semaines.	Activité de test, rapport Excel
	Graphique en aires empilées qui indique le nombre cumulé de tous les résultats négatifs des cas de test, triés par type d'échec, au cours des quatre dernières semaines. Les types d'échec sont Régression, Nouveau problème et Problème connu.	Analyse de l'échec, 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 : la génération a partiellement réussi	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 surveiller les efforts de test

Pour que les rapports du tableau de bord de test soient utiles et précis, l'équipe doit mettre en œuvre les activités suivantes :

Définir des cas de test et des récits utilisateur ou des spécifications, et créer des liens Testé par entre les cas de test et les récits utilisateur ou les spécifications.
Définir des plans de test et leur attribuer 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.

Surveiller la progression des tests

Vous pouvez utiliser les trois premiers rapports du tableau de bord Test pour surveiller la progression des tests et répondre aux questions du tableau suivant.

Rapport	Questions répondues	Remarques
Disponibilité du cas de test	Combien de cas de test l'équipe des tests a-t-elle défini ? Combien de cas de test sont prêts à être exécutés aujourd'hui ? Combien de cas de test l'équipe doit-elle encore rédiger et réviser ? Le nombre total de cas de test semble-t-il être suffisant pour le nombre de récits utilisateur implémentés par l'équipe ? Quel pourcentage de cas de test l'équipe des tests peut-elle exécuter aujourd'hui ? L'équipe sera-t-elle en mesure de préparer tous les cas de test d'ici la fin de l'itération ?	Une progression correcte indique une augmentation continue du nombre de cas de test conçus par l'équipe et possédant l'état Prêt. Une progression incorrecte indique aucun ou un nombre limité de cas de test prêts à être exécutés. Lorsque tous les cas de test restent à l'état Design pendant longtemps, c'est qu'un problème bloque sans doute la progression. Vous pouvez rechercher la cause de ce blocage. Un écart de test peut survenir si le nombre de cas de test n'apparaît pas suffisant. Le nombre de cas de test définis pour un projet doit être supérieur ou égal au nombre de récits utilisateur implémentés par l'équipe. Le nombre de cas de test ne semble pas être suffisant.
Progression du plan de test	Combien de cas de test réussissent ? Combien de cas de test échouent ? Combien de cas de test sont bloqués ? Combien de cas de test ne sont jamais exécutés ? Quel pourcentage de cas de test réussissent dans tous les plans de test ? Combien de tests l'équipe a-t-elle effectué ? L'équipe est-elle susceptible de terminer l'itération dans les temps ?	À mesure que le cycle de développement progresse, le nombre de cas de test qui réussissent doit augmenter et le nombre de cas de test possédant un autre état doit diminuer. Une progression incorrecte se produit quand trop de cas de test échouent. Selon la phase du cycle de produit dans laquelle vous vous trouvez, vous pouvez rechercher la raison de l'échec d'un si grand nombre de cas de test. Si le nombre de cas de test qui échouent ou ne sont jamais exécutés reste stable, vous pouvez étudier les causes spécifiques qui affectent chaque zone.
État du test du récit utilisateur État du test des spécifications	Des cas de test sont-ils exécutés pour chaque récit utilisateur ou spécification ? Si des cas de test sont bloqués ou non exécutés, l'équipe a-t-elle identifié les problèmes majeurs et est-elle en train de les corriger ?	Une progression correcte indique que la plupart des cas de test de chaque récit utilisateur ou spécification réussissent. Une progression incorrecte indique un trop grand nombre de cas de test pour une spécification ou récit utilisateur précis avec l'état Jamais exécuté, Bloqué ou Échec. Vous pouvez étudier les causes qui empêchent les cas de test définis pour un récit utilisateur ou une spécification de réussir.

Disponibilité du cas de test

Combien de cas de test l'équipe des tests a-t-elle défini ?
Combien de cas de test sont prêts à être exécutés aujourd'hui ?
Combien de cas de test l'équipe doit-elle encore rédiger et réviser ?
Le nombre total de cas de test semble-t-il être suffisant pour le nombre de récits utilisateur implémentés par l'équipe ?
Quel pourcentage de cas de test l'équipe des tests peut-elle exécuter aujourd'hui ?
L'équipe sera-t-elle en mesure de préparer tous les cas de test d'ici la fin de l'itération ?

Une progression correcte indique une augmentation continue du nombre de cas de test conçus par l'équipe et possédant l'état Prêt.
Une progression incorrecte indique aucun ou un nombre limité de cas de test prêts à être exécutés.

Lorsque tous les cas de test restent à l'état Design pendant longtemps, c'est qu'un problème bloque sans doute la progression. Vous pouvez rechercher la cause de ce blocage.
Un écart de test peut survenir si le nombre de cas de test n'apparaît pas suffisant.

Le nombre de cas de test définis pour un projet doit être supérieur ou égal au nombre de récits utilisateur implémentés par l'équipe. Le nombre de cas de test ne semble pas être suffisant.

Progression du plan de test

Combien de cas de test réussissent ?
Combien de cas de test échouent ?
Combien de cas de test sont bloqués ?
Combien de cas de test ne sont jamais exécutés ?
Quel pourcentage de cas de test réussissent dans tous les plans de test ?
Combien de tests l'équipe a-t-elle effectué ?
L'équipe est-elle susceptible de terminer l'itération dans les temps ?

À mesure que le cycle de développement progresse, le nombre de cas de test qui réussissent doit augmenter et le nombre de cas de test possédant un autre état doit diminuer.
Une progression incorrecte se produit quand trop de cas de test échouent. Selon la phase du cycle de produit dans laquelle vous vous trouvez, vous pouvez rechercher la raison de l'échec d'un si grand nombre de cas de test.
Si le nombre de cas de test qui échouent ou ne sont jamais exécutés reste stable, vous pouvez étudier les causes spécifiques qui affectent chaque zone.

État du test du récit utilisateur

État du test des spécifications

Des cas de test sont-ils exécutés pour chaque récit utilisateur ou spécification ?
Si des cas de test sont bloqués ou non exécutés, l'équipe a-t-elle identifié les problèmes majeurs et est-elle en train de les corriger ?

Une progression correcte indique que la plupart des cas de test de chaque récit utilisateur ou spécification réussissent.
Une progression incorrecte indique un trop grand nombre de cas de test pour une spécification ou récit utilisateur précis avec l'état Jamais exécuté, Bloqué ou Échec. Vous pouvez étudier les causes qui empêchent les cas de test définis pour un récit utilisateur ou une spécification de réussir.

Déterminer des écarts de tests

Vous pouvez utiliser le rapport État du test du récit utilisateur ou État du test des spécifications pour déterminer si les tests couvrent tout le code et pour répondre aux questions suivantes :

Pour quels récits utilisateur ou spécifications le nombre total de cas de test est-il faible ?
Pour quels récits utilisateur ou spécifications le nombre total de cas de test bloqués ou jamais exécutés est-il élevé ?
La couverture des cas de test de chaque récit utilisateur ou spécification répond-elle aux attentes ?
Quels récits utilisateur ou spécifications ont un taux d'échecs aux tests élevé ?
Quel est le nombre moyen de cas de test définis pour chaque récit utilisateur ou spécification ?

Surveiller les échecs et régressions de tests

En surveillant les échecs de test, vous pouvez identifier et résoudre rapidement les problèmes de code. Les deux derniers rapports du tableau de bord Test vous permettent de mieux visualiser le nombre des tests qui échouent.

Rapport	Questions répondues	Remarques
Activité de test manuel	Le nombre de tests que l'équipe n'a jamais exécutés a-t-il diminué ? L'équipe parvient-elle à réduire le nombre global de tests bloqués ? Le nombre de tests qui échouent diminue-t-il avec le temps ? Le nombre de tests qui réussissent augmente-t-il ? L'activité de test connaît-elle des pics que vous ne pouvez pas expliquer ?	Le rapport Activité de test manuel indique les résultats de chaque cas de test exécuté pour chaque configuration de test et pour tous les plans de test. Les pics d'activité éventuels peuvent être les premiers indicateurs de problèmes liés à l'activité de test ou à la qualité du code archivé. Vous pouvez vérifier les mesures des builds récentes, l'état des bogues et l'évolution du code pour déterminer si l'un de ces éléments peut expliquer les changements.
Analyse de l'échec du test	Combien de tests sont-ils en régression ? L'équipe conserve-t-elle le nombre total de régressions ou d'échecs de test dans les limites ou objectifs attendus ? L'équipe traite-t-elle les problèmes dès qu'ils sont identifiés et les problèmes connus en temps voulu ?	Un rapport Analyse de l'échec du test correct affiche un nombre modéré de nouveaux problèmes, de problèmes connus et de régressions. Si des pics d'activité se produisent dans ces zones, l'équipe devra peut-être étudier la question de façon plus approfondie. Les pics peuvent indiquer des problèmes dans l'activité de test ou dans la qualité du code archivé. De plus, vous pouvez vérifier les mesures des builds récentes, l'état des bogues et l'évolution du code pour déterminer si l'un de ces éléments peut expliquer les changements.

Activité de test manuel

Le nombre de tests que l'équipe n'a jamais exécutés a-t-il diminué ?
L'équipe parvient-elle à réduire le nombre global de tests bloqués ?
Le nombre de tests qui échouent diminue-t-il avec le temps ?
Le nombre de tests qui réussissent augmente-t-il ?
L'activité de test connaît-elle des pics que vous ne pouvez pas expliquer ?

Le rapport Activité de test manuel indique les résultats de chaque cas de test exécuté pour chaque configuration de test et pour tous les plans de test. Les pics d'activité éventuels peuvent être les premiers indicateurs de problèmes liés à l'activité de test ou à la qualité du code archivé.

Vous pouvez vérifier les mesures des builds récentes, l'état des bogues et l'évolution du code pour déterminer si l'un de ces éléments peut expliquer les changements.

Analyse de l'échec du test

Combien de tests sont-ils en régression ?
L'équipe conserve-t-elle le nombre total de régressions ou d'échecs de test dans les limites ou objectifs attendus ?
L'équipe traite-t-elle les problèmes dès qu'ils sont identifiés et les problèmes connus en temps voulu ?

Un rapport Analyse de l'échec du test correct affiche un nombre modéré de nouveaux problèmes, de problèmes connus et de régressions. Si des pics d'activité se produisent dans ces zones, l'équipe devra peut-être étudier la question de façon plus approfondie. Les pics peuvent indiquer des problèmes dans l'activité de test ou dans la qualité du code archivé.

De plus, vous pouvez vérifier les mesures des builds récentes, l'état des bogues et l'évolution du code pour déterminer si l'un de ces éléments peut expliquer les changements.

Voir aussi

Tableaux de bord de portail de projet

Partager via