Le Cockpit avant tout choix de plan : rien n'est calculé tant que vous n'en avez pas sélectionné un.
La réponse d’abord
Avec une date cible et au moins trois jours ouvrés d’exécution, l’en-tête donne en une phrase :- le rythme observé — tests par jour ouvré, en moyenne sur les trois derniers jours ouvrés ayant vu des exécutions ;
- la fin projetée ;
- l’écart à la cible, en jours ouvrés ;
- le rythme nécessaire — ce qui reste divisé par les jours ouvrés restants.
Le Cockpit préfère un silence honnête à une date inventée. Avec moins de trois jours ouvrés d’historique, aucune projection n’est faite, et la phrase le dit. Une campagne terminée, pas démarrée, sans date ou à l’arrêt — sa dernière exécution trop ancienne pour en extrapoler quoi que ce soit — a chacune sa propre phrase plutôt qu’un chiffre.
Depuis le dernier point
Une ligne : tests exécutés, réussis et échoués, combien d’échecs sont nouveaux, bugs ouverts et résolus, tests débloqués, changements de périmètre — comparés au dernier snapshot d’un jour ouvré précédent. Quand ce snapshot n’est pas celui de la veille, sa date est écrite. Un snapshot capturé par une version antérieure de TestPulse ne porte pas de quoi dire quels échecs sont nouveaux ni quels bugs ont été fermés : ces éléments sont retirés de la ligne — jamais affichés à zéro.La date tient-elle ?
Un burndown pleine largeur en points de test (cas × suite × configuration) : la courbe réelle, la ligne idéale, la projection, la cible, un repère ce matin et les changements de périmètre, annotés sur la courbe. Les changements de périmètre sont montrés, pas lissés : ajouter, retirer ou redimensionner une suite ou une configuration apparaît comme une marche légendée. Une suite supprimée puis recréée pour la même exigence est rapprochée comme une réorganisation — par l’exigence seule, jamais par le nom. Un simulateur — testeurs × tests par testeur et par jour, initialisé sur ce qui a réellement été observé — déplace la projection. C’est un état de session, jamais enregistré. L’estimation du pur temps d’exécution reste disponible en information secondaire.Quoi exécuter aujourd’hui, par raison
Les tests sont regroupés selon la raison de leur présence, dans cet ordre :- échecs à rejouer ;
- tests débloqués depuis le dernier point ;
- tests de haute priorité jamais exécutés ;
- suites en retard ;
- autres tests jamais exécutés.
Ce qui bloque
Les tests bloqués par un bug ouvert (avec son âge et sa sévérité), les échecs sans bug lié et les tests sans testeur. Chaque ligne mène à l’action.Le Cockpit lit les liens Tested By des cas de test, quelle que soit la source des bugs choisie pour les rapports.
Charge par testeur
Une carte liste, pour chaque testeur assigné, les tests qui restent, son rythme observé et la fin qu’il donne, plus un lot non assigné — avec un lien vers la Réaffectation en masse. Le Cockpit lui-même ne réaffecte rien. Les testeurs proviennent des points de test déjà chargés pour l’en-tête : aucun appel supplémentaire. Parce que cette carte nomme des personnes et leur rythme, un projet peut la désactiver dans Paramètres › Cockpit (Afficher la charge par testeur, activé par défaut). C’est un réglage projet : une fois désactivée, la carte disparaît pour tous les membres du projet, une ligne discrète indique où elle a été désactivée, et les testeurs ne sont même pas lus. Le réglage affiche qui l’a modifié en dernier, et quand. S’il ne peut pas être lu, le Cockpit s’ouvre avec la valeur par défaut.Une campagne pas encore démarrée
Jamais d’écran vide : le rythme nécessaire dès le premier jour, la charge par testeur, par où commencer, et ce que chaque bloc montrera une fois sa condition remplie.Détails, repliés
L’avancement par suite et le journal de périmètre se trouvent dessous, repliés. Les snapshots sont capturés une fois par jour et par plan, dès que le hub est ouvert ou qu’un rapport est généré (le dernier de la journée l’emporte), si bien que la courbe reste juste quand le périmètre bouge. Le Cockpit est mono-plan.Ce qu’il lit
Aucune nouvelle permission, aucune nouvelle dépendance. La seule lecture ajoutée récupère les liens entre les cas de test du plan et leurs bugs et exigences (avec leurs priorités), dans les mêmes appels groupés de work items que TestPulse fait déjà — et seulement après l’affichage de l’en-tête : la réponse ne l’attend jamais. Fonctionne sur Azure DevOps Services et Azure DevOps Server 2022.1.Ce que cet écran a remplacé
Avant la v2.72.4, le Cockpit classait Quoi exécuter aujourd’hui par un score pondéré selon trois profils — Strict / Standard / Onboarding — à côté de tuiles KPI et de curseurs de charge restante. Le sélecteur de profil et la liste scorée disparaissent : un test apparaît désormais pour une raison lisible — il a échoué, il a été débloqué, son exigence est prioritaire, sa suite est en retard — et non pour un poids. La phrase d’en-tête et le simulateur ont pris la place des tuiles et des curseurs. Le profil qu’un projet avait choisi n’est plus lu, et il n’est pas supprimé. Les snapshots capturés par les versions antérieures sont lus tels quels, sans migration. Les rapports, les exports et le widget sont inchangés.À suivre
Réaffectation en masse
Agir sur ce que montre la charge par testeur.
Quality Gate & GO/NO-GO
Du pilotage quotidien à la décision de release.
Lecture seule par conception
Où vivent les snapshots et ce qui n’est jamais écrit.