Changelog

Les versions récentes sont détaillées ci-dessous. L’historique complet depuis la toute première version vit dans le changelog du dépôt.

2026-09-09

Une ligne de rapport PDF pouvait sortir illisible, lettre à lettre, dès qu’elle portait un caractère que la police du PDF ne sait pas dessiner. La décision de passage d’une session exploratoire — la ligne qu’un comité de changement lit en premier — s’imprimait Q U A L !' P R O D — O K au lieu de QUAL > PROD — OK.

La cause tenait à une seule flèche. Le moteur PDF bascule la chaîne entière dans un encodage sur deux octets dès qu’un caractère sort du répertoire de la police, puis l’écrit dans une police incapable de la relire : chaque lettre se retrouve précédée d’un octet qui ne dessine rien, et le caractère fautif se lit comme deux glyphes parasites. Un seul caractère suffisait à casser toute une ligne.
Sept endroits portaient le même défaut, quatre d’entre eux depuis des mois : la bande de décision et la plage de dates du rapport de sessions agrégé, l’override de décision humaine et la table des tests instables du rapport standard, le détail des pas, les lignes Epic de la traçabilité et le marqueur exigence périmée.
Les sept sont corrigés d’un coup et par un mécanisme unique plutôt qu’un rustine chacun : chaque rapport fait désormais passer son texte par un seul endroit avant de le dessiner, tables comprises. Un nouvel écran ne peut plus rendre un rapport illisible en oubliant de le faire.
La typographie française n’est pas touchée. Tirets cadratins, points de suspension, apostrophes courbes, guillemets, puces, œ et € font tous partie de ce que la police du PDF sait dessiner, et s’impriment exactement comme avant — vérifié caractère par caractère. Seule change la poignée de symboles qu’elle n’a jamais su dessiner : une flèche s’imprime >, le marqueur de pas ->, le marqueur Epic -, le panneau d’avertissement (!). Partout ailleurs dans le produit — le commentaire de la fiche, le dialogue de clôture, le rapport HTML — une flèche reste une flèche. Le PDF est la surface contrainte, c’est lui qui s’adapte.
Un caractère auquel nous n’avons pas donné de forme imprimée devient désormais un ? visible plutôt que de disparaître : un trou muet dans un rapport signé est pire qu’un point d’interrogation qu’on peut voir et signaler. Un tel caractère subsiste aujourd’hui — le ≈ de la ligne charge restante de la page métriques, qui s’imprime Reliquat ? 1 j-testeur. Il était illisible avant cette version, il n’est plus qu’imparfait ; lui donner une forme imprimée est une décision distincte.

2026-09-09

À la clôture d’une session exploratoire, vous pouvez désormais acter si la livraison peut passer au palier d’environnement suivant — et cette décision atterrit là où le comité de changement regarde vraiment. Jusqu’ici cette conclusion se prenait hors de l’outil et n’apparaissait nulle part sur la fiche que le comité examine. Voir Décision de passage.

Chaque projet démarre sur une échelle proposée — TEST → QUAL → PROD — qu’un administrateur peut renommer, réordonner, allonger ou raccourcir dans Réglages › Environnements. Choisir le palier au démarrage d’une session est facultatif et rien n’est pré-sélectionné ; sans palier, aucune décision n’est proposée et la session se comporte exactement comme avant. Vider l’échelle désactive la fonctionnalité pour tout le projet.
À la clôture, un bloc Décision de passage apparaît sous le verdict, avec la transition (QUAL → PROD, ou Validé en PROD sur le dernier palier) et trois valeurs : OK, Réservé, Bloqué — un commentaire est obligatoire pour les deux dernières. La décision est facultative, définitive une fois la session close, et comptée nulle part : ni taux de réussite, ni score qualité, ni GO / NO-GO, ni export de campagne.
Elle est écrite à trois endroits : un tag requêtable sur la tâche de session (Passage:QUAL>PROD:OK), une bande colorée sur la page de garde du PDF de session avec le commentaire et une ligne d’audit, et — nouveau pour TestPulse — un tag et un commentaire de discussion sur la fiche depuis laquelle la session a été menée.
Cette dernière écriture est bornée de tous les côtés : une seule cible (la fiche depuis laquelle la session a été menée), deux champs (ses tags et un commentaire — jamais un état, une affectation ou un lien), un seul déclencheur (votre clic sur Clôturer avec une décision sélectionnée, après qu’un encadré a nommé la fiche et montré le tag exact), un seul interrupteur (un administrateur peut la désactiver). Seule une décision précédente sur la même transition est remplacée.
Elle n’est par ailleurs jamais bloquante. Si la fiche porte des modifications non enregistrées, l’écriture est sautée plutôt que de risquer un conflit avec votre propre enregistrement — on vous dit quoi faire. Si Azure DevOps la refuse, la session se clôt quand même, la tâche est créée, la décision est enregistrée et exportée, et le message reprend le libellé d’Azure DevOps tel quel. Le cas survenu est imprimé sur la ligne d’audit du PDF : un rapport ne revendique jamais une écriture qui n’a pas eu lieu.

2026-09-07

La zone de dépôt d’une session exploratoire est désormais impossible à rater, et un dépôt manqué ne coûte plus la session. Déposer un enregistrement Win+G ou un log sur la frise revenait à viser un bandeau d’environ 40 px de haut, sans le moindre retour visuel et sans alternative au glisser. À côté, le navigateur faisait ce qu’un navigateur fait d’un fichier lâché sur une page : il l’ouvrait dans l’onglet, et la session en cours quittait l’écran.

La zone reprend le motif que l’onglet Import emploie depuis des mois — bordure pointillée, icône, titre, ligne d’explication et bouton Parcourir…, sur au moins 100 px de haut. Sa taille ne change jamais pendant la session : une cible qui bouge est une cible à retrouver.
Pendant que vous glissez un fichier, tout le panneau de frise devient la cible. Une superposition le couvre et annonce ce que le dépôt va faire, et lâcher n’importe où sur le panneau est traité exactement comme si vous aviez visé la zone. Traverser un élément interne au panneau ne fait pas clignoter cette superposition, et glisser du texte sélectionné ne la fait pas apparaître du tout — seuls les fichiers la lèvent.
Un fichier lâché à côté du panneau est désormais avalé : le navigateur ne navigue pas, rien n’est joint, et votre session reste à l’écran. Ce garde vit dans le seul onglet Explore et disparaît avec lui — le glisser-déposer de l’onglet Référentiel n’est pas touché.
Le bouton Parcourir… ouvre le sélecteur natif, pour un fichier que le glisser n’atteint pas ou simplement si vous préférez une boîte de dialogue. Aucun filtre de type n’est appliqué : la limite de taille reste celle d’Azure DevOps, pas une devinette de notre part.

Déposer plusieurs fichiers d’un coup les joint désormais tous, et un échec en cours de route est nommé. La frise n’acceptait qu’un fichier par dépôt. Les fichiers partent maintenant l’un après l’autre, chaque entrée calculée depuis la session telle qu’elle est à cet instant — une note saisie pendant que le lot part est conservée, pas écrasée. Une ligne de progression indique le rang, le total et le nom du fichier en cours, et un second dépôt tenté pendant un lot est ignoré, sans erreur.

Si le deuxième de trois fichiers est refusé, le premier et le troisième restent joints, et le message nomme le deuxième avec le libellé d’Azure DevOps tel quel. Rien n’est annulé — ce qui est joint reste joint.
Le seul échec qui interrompt un lot est un échec de permission : le bandeau de ré-approbation est levé, et les fichiers restants ne sont pas tentés.
Un fichier lâché sur la zone elle-même était par ailleurs envoyé deux fois, la zone et le panneau traitant chacun le dépôt. Le panneau est désormais le seul à le faire.

Voir Capturer & créer.

2026-09-04

Dans le rapport standard, le nom d’un fichier joint est désormais un lien, et son type est lisible. Un fichier attaché à un résultat de test apparaissait déjà dans le PDF, dans un tableau Fichier / Type / Taille — mais le nom était du texte mort, et le seul moyen de l’ouvrir était d’aller le chercher à la main dans Azure DevOps. Le rapport HTML, lui, porte ce lien depuis toujours : l’écart était entre nos propres surfaces.

Le nom du fichier est rendu en lien vers la pièce jointe. Toute pièce jointe est cliquable, quelle que soit son extension — une extension que nous ne reconnaissons pas change le libellé, jamais le lien. Une limite de notre propre table ne doit pas vous coûter votre accès.
La colonne Type affichait application/octet-stream pour tout ce qui n’était pas une image, cette valeur venant d’une table qui ne connaissait que six extensions, toutes des formats d’image. Elle affiche maintenant un libellé lisible dérivé du nom de fichier : PDF, Word, Excel, PowerPoint, CSV, JSON, XML, Archive, E-mail, Texte, Log, Image, et un simple Fichier pour le reste. Cette table n’est pas exhaustive et ne prétend pas l’être — le repli est le comportement nominal, pas un défaut.
Le lien n’est omis que lorsqu’il n’y a rien à lier : URL absente, ou protocole autre que http ou https. Le nom est alors en texte simple.
Les images embarquées, le partage images / non-images de la page, l’estimation de hauteur et la pagination sont inchangés.

La section Pièces jointes est désormais affichée par défaut, sur le PDF comme sur le rapport HTML.

Tout ce qu’elle montre était déjà lu dans Azure DevOps à chaque génération : rien de plus n’est récupéré — le rapport cesse simplement de jeter une donnée déjà payée.
Énoncé plutôt que découvert après coup : si vous n’aviez jamais touché à la liste des sections, vos rapports porteront désormais une page Pièces jointes, et le rapport HTML affichera la sienne.
Rien de ce que vous avez enregistré n’est réécrit. Un rapport dont vous aviez déjà choisi les sections conserve votre choix, y compris une section que vous aviez volontairement désactivée.
Le bouton Réinitialiser des paramètres renvoie maintenant les défauts réels, au lieu d’une liste recopiée à la main qui aurait continué d’indiquer Pièces jointes : désactivé.
Les captures d’écran des étapes relèvent d’un réglage distinct et ne sont pas touchées.

2026-09-04

Les preuves d’une session sont désormais listées dans le rapport, et le PDF permet de les ouvrir. Un fichier déposé dans une session exploratoire part bien dans Azure DevOps en pièce jointe du work item — mais le rapport se contentait de le mentionner au passage : il annonçait une preuve sans donner aucun moyen d’y accéder.

Les deux surfaces portent maintenant une section Preuves listant chaque pièce jointe de la session, fichiers déposés et captures collées confondus, avec son nom, son horodatage et sa taille, en ordre chronologique. Pas de pièce jointe, pas de section.
Le rapport écrit dans la tâche de suivi est un registre : écrit une seule fois à la clôture et jamais repris, il liste ce qui a été produit et ne porte aucun lien. L’accès réel est à un onglet de là, sur le même work item, et cet onglet reflète toujours la réalité.
Le PDF est la surface d’accès — la seule qui voyage hors d’Azure DevOps, et la seule qui puisse dire la vérité au moment où elle est produite. C’est là que vivent les liens.
À la génération, un seul appel groupé lit quelles pièces jointes sont encore rattachées à la tâche. Celle qui n’y est plus affiche Pièce jointe indisponible au lieu de proposer un lien mort. Jamais une requête par fichier — et si cet appel échoue, rien n’est conclu et tous les liens s’affichent normalement, parce qu’un incident réseau ne doit jamais ressembler à une preuve supprimée.
Une image que vous avez déposée reste une ligne de pièce jointe plutôt qu’une vignette ; seules les captures collées sont intégrées. Cette distinction est volontaire.

Chaque ligne de session porte sa date et son heure de démarrage, et les sessions sont triées à l’intérieur de chaque story.

Déplier une story listait ses sessions dans l’ordre où le stockage les rendait, sans aucune date affichée : sur une story portant quatre sessions, rien ne disait laquelle était la plus récente.
Chaque ligne indique maintenant quand la session a démarré — date et heure, formatées dans votre langue — de sorte que deux sessions menées le même jour se distinguent sans en ouvrir aucune.
Au sein d’une story, les sessions vont de la plus récente à la plus ancienne, et toute session encore ouverte se place en tête : c’est celle que vous revenez terminer. L’ordre entre stories est inchangé.

Trois correctifs autour des sessions dont la tâche de suivi n’existe plus.

Dans l’onglet Explore de la story, la liste des sessions précédentes construisait son lien directement depuis l’identifiant stocké, sans jamais vérifier que la tâche existait encore — le clic tombait sur une page d’erreur. L’historique vérifie désormais chaque tâche de suivi en une seule lecture groupée : celle qui reste introuvable perd son lien et affiche La tâche associée n’est plus disponible. Jamais « supprimée » — un work item supprimé part à la corbeille et reste restaurable, et une lecture groupée ne distingue pas les deux cas. Restaurez-le et le lien revient au rafraîchissement suivant.
Dans le hub, cette même session disparaissait purement et simplement de l’inventaire. Le hub résout le testeur d’une session depuis sa tâche de suivi, et il applique de lui-même un filtre Testeur à l’ouverture : testeur non résolu plus filtre par défaut, la session était silencieusement retirée d’un inventaire présenté comme complet. Un filtre que vous choisissez est une intention et masque toujours ce qu’il doit ; un filtre appliqué pour vous ne retire plus rien que vous n’ayez demandé. La ligne conserve son bouton Exporter : l’enregistrement de la session est intact, seule sa matérialisation manque.
Le filtre de période excluait le jour même qu’il prétendait inclure : demander les sessions du 31/08 au 31/08 ne renvoyait rien, même avec une session démarrée cet après-midi-là. Les deux bornes comparent maintenant des jours calendaires tels que vous les voyez à l’écran, dans votre propre fuseau, jamais un instant. La période imprimée sur la couverture du PDF agrégé suit la même règle.

2026-09-01

Relire le même plan après une réaffectation affichait l’état d’avant. Revenir à la première étape fonctionnait et la liste des plans était bien relue, mais resélectionner le même plan ramenait exactement ce que vous aviez vu avant d’appliquer — seul un rechargement complet de la page montrait la réalité.

Les test points d’une suite étaient gardés en mémoire pour toute la session et rien ne les effaçait jamais : la seconde lecture servait un instantané pris avant l’écriture. Les suites qu’une opération touche sont désormais évincées de cette mémoire dès qu’elle se termine.
Les suites en échec le sont aussi. Un conflit signifie que la suite a bougé ; une erreur de droits laisse un doute sur ce qui est réellement passé. Une relecture coûte un appel, un chiffre faux coûte plus cher.
Tout le reste demeure en mémoire : les plans que l’opération n’a pas touchés s’ouvrent aussi vite qu’avant, et rejouer les points en échec se comporte de la même manière.
Cela vaut désormais aussi quand des cas de test sont ajoutés à une suite existante depuis le référentiel — le contenu de cette suite est relu, plutôt que servi d’avant l’écriture.

2026-08-31

Enchaîner une réaffectation ramène à la première étape, sur une liste de plans fraîche. Et une vue sauvegardée ne produit plus un rapport daté d’il y a des mois.

La v2.67.0 conservait le périmètre choisi et reconstruisait son inventaire derrière un écran dédié. À l’usage, c’était désorientant : on atterrissait sur un inventaire sans savoir s’il montrait l’état d’avant ou d’après l’opération qu’on venait d’appliquer. Vous revenez maintenant à Périmètre, rien de présélectionné, liste des plans relue — un plan créé, renommé ou supprimé entre-temps apparaît tel qu’il est.
L’écran de reconstruction dédié disparaît. Le balayage qu’il dupliquait est celui qu’Analyser le périmètre annonce depuis toujours, avec la même progression par suite et le même bouton d’annulation. Deux clics de plus, et on sait toujours où l’on est.
Ouvrir une vue sauvegardée pose désormais la date du jour. Une vue enregistre les métadonnées avec lesquelles elle a été sauvegardée, date du rapport comprise, et les réappliquait à l’ouverture : une vue enregistrée en juin et rouverte en août générait un rapport daté de juin — et un fichier Excel nommé d’après cette date, puisque le nom en dérive. Une vue est un modèle réutilisable, pas un instantané.
Rien n’est réécrit dans la vue : sa date enregistrée lui reste acquise jusqu’à un nouvel enregistrement. Un bandeau non bloquant énonce les deux dates et propose de restaurer celle enregistrée, pour le cas rare d’un rapport passé à régénérer — et ne dit rien du tout si la vue a été enregistrée le jour même. Modifier la date à la main le fait disparaître : vous avez tranché.
Un rapport programmé porte la date de l’exécution qui l’a produit, sans bandeau — personne n’est devant l’écran. La date lue est la date locale, un rapport généré à onze heures et demie du soir n’est donc pas daté de demain.

2026-08-31

Le catalogue de configurations annoncé en v2.67.0 n’a jamais été réellement chargé. L’appel qui lit les configurations d’un projet répondait 404 depuis la fonctionnalité qui l’a introduit, et l’échec était avalé en silence.

Le catalogue de configurations du projet est de nouveau lu. L’appel visait la zone historique avec une version d’API qu’elle ne connaît pas, et renvoyait 404 aussi bien dans le cloud qu’en on-premises. Il vise maintenant la route des plans de test, avec l’historique en v5.0 en repli — le motif déjà employé pour les plans, les suites et les points. Ce n’est pas un appel de plus : c’est le même appel, à la bonne adresse.
Quand les deux routes échouent, l’écran le dit et retombe sur les configurations du périmètre, au lieu de la liste vide silencieuse d’avant.
Au-delà de la réaffectation en masse, l’indicateur Configurations couvertes du rapport (X / Y) retrouve son Y, bloqué à zéro jusqu’ici.
Une configuration marquée inactive dans le projet est désormais signalée comme telle. Elle reste sélectionnable — la masquer surprendrait autant que l’offrir sans avertissement — mais elle le dit en toutes lettres et se place en fin de liste de destination, derrière tout ce qui est encore actif.

2026-08-31

La réaffectation en masse ne savait réaffecter que vers quelqu’un — ou quelque chose — de déjà présent. Les deux listes de destination étaient bâties sur le périmètre lui-même : une configuration définie dans le projet mais portée par aucun point, et un testeur ne portant aucun point, ne pouvaient tout simplement pas être choisis.

Toute configuration définie dans le projet peut désormais être une destination. La liste de destination est le catalogue projet, et non l’inventaire de ce que le périmètre porte déjà. Chaque entrée indique combien de points du périmètre la portent, et celle qui n’en porte aucun le dit en toutes lettres, pas seulement par la couleur — tout en restant sélectionnable. La liste depuis laquelle vous remplacez ne change pas : elle reste l’inventaire du réel, parce que c’est une autre question.
Tout testeur peut désormais être une destination. Le champ recherche les identités — 500 ms après la fin de la saisie, à partir de trois caractères — et résout votre choix vers une identité réelle plutôt que vers le texte tapé. Réaffecter un test point exige l’identité elle-même : un nom jamais résolu n’aurait échoué qu’après le récapitulatif, une fois convaincu que l’opération allait passer.
Les testeurs déjà présents dans le périmètre sont proposés d’emblée, sans saisie ni recherche, et Non assigné reste disponible. Là où la recherche d’identités est restreinte — c’est possible sur Azure DevOps Server — le champ le dit et retombe sur ces testeurs connus, au lieu de laisser un champ vide.

2026-08-31

La réaffectation en masse devient utilisable aux volumes réels. Deux sélecteurs qui tenaient sur un plan de démonstration n’ont pas survécu à 175 plans et à un arbre de 172 suites.

Rechercher un plan au lieu de faire défiler la liste. L’étape Périmètre porte désormais un champ de recherche, en mode mono-plan comme en multi-plans, qui filtre sur le nom du plan, l’itération ou un identifiant exact. Il filtre la liste déjà chargée — il ne va jamais rien chercher au dehors. Le filtre masque, il ne désélectionne jamais : un plan sélectionné que la recherche cache reste sélectionné, et le compteur continue d’afficher le total réel.
Choisir une suite de départ dans son arborescence, plus dans une liste plate. Les suites s’affichent hiérarchiquement, avec repli et dépli par nœud, tout déplier et tout replier, et une recherche par nom qui garde un résultat visible avec ses ancêtres. Chaque nœud affiche les mêmes chiffres qu’avant — sous-suites et points de son sous-arbre — simplement à un endroit plus lisible.
Une suite sans test point ne masque plus ses enfants. La liste plate était bâtie sur les test points : une suite n’en portant aucun n’y figurait pas. Sans conséquence en liste, mais en arborescence cela rendait chaque descendant inatteignable. L’arbre est désormais construit sur la relation parent-enfant. Une suite dont tout le sous-arbre est vide s’affiche désactivée et le dit en toutes lettres, pas seulement par la couleur.
Une hiérarchie de suites incohérente ne vide plus le sélecteur. Une chaîne de parents qui boucle sur elle-même — possible sur un serveur on-premises ancien — laissait l’arbre sans racine et faisait disparaître toutes les suites de l’écran. Une telle chaîne est maintenant rompue en un point et les suites sont affichées au premier niveau.

2026-08-31

Consigné après coup : cette version a été publiée sans note de version. Son contenu est décrit ici.

Réaffecter le testeur ou la configuration de tout un plan de test en une passe. Azure DevOps sait assigner des testeurs au niveau d’une suite, mais l’action ne cascade pas vers les suites enfants — un plan de 172 suites imposait donc d’en ouvrir jusqu’à 172 pour 296 points. Ni l’import CSV ni la grille d’édition en masse ne peuvent atteindre ces deux propriétés : elles appartiennent au test point, pas au work item Cas de test.

Un nouvel onglet Réaffectation en masse parcourt le plan, inventorie l’existant et applique le changement en une passe — sur un plan, ou jusqu’à dix à la fois.
Voir la répartition actuelle avant de décider quoi que ce soit. Testeurs et configurations côte à côte, triés par volume, chaque ligne indiquant son nombre de points, combien portent déjà un résultat d’exécution, et sa part du périmètre. Une configuration pesant moins de 2 % des points est marquée résiduelle. Non assigné est une ligne à part entière, pas une absence. Rien n’est mis en cache : l’inventaire est reconstruit à chaque analyse et porte l’horodatage de sa lecture.
Trois manières de définir ce qui change — remplacer une ou plusieurs valeurs par une autre, appliquer à tout le périmètre, ou appliquer à une suite et à toutes ses sous-suites, récursivement et à n’importe quelle profondeur.
Un récapitulatif obligatoire avant toute écriture. Points concernés, suites touchées, points déjà exécutés, cas ignorés et nombre d’appels API estimé — plus l’opération en langage clair et l’endpoint exact qui sera appelé. Le bouton d’application reste désactivé tant que l’impact est nul, et l’état antérieur peut être exporté en CSV au préalable.
Changer un testeur et changer une configuration ne sont pas la même opération, et l’interface le dit. Changer le testeur conserve le test point et son résultat. Changer la configuration réécrit les affectations du cas de test, ce qu’Azure DevOps peut implémenter en détruisant le point et en le recréant — emportant son résultat. Endpoints différents, avertissements différents, et sous-titre différent sur le choix « inclure les points déjà exécutés ».
Un cas de test portant déjà la configuration cible est ignoré, jamais fusionné — fusionner supprimerait l’une de ses affectations. Ces cas sont listés avec leur suite et leur identifiant, et exportables en CSV.
L’opération est irréversible, et le dit. Azure DevOps ne propose aucune annulation et TestPulse ne conserve aucun état antérieur — une décision délibérée, pas un oubli. Voir Lecture seule par défaut.
Un échec partiel est un résultat valide, pas un état corrompu. Rien n’est annulé : les points déjà réaffectés le restent. Le rapport liste chaque échec avec son code HTTP et une cause en clair, et un bouton de reprise ne rejoue que les échecs.

2026-08-30

Le verdict qualité durcit, délibérément — et certains rapports passeront désormais en NO-GO.Deux nouveaux planchers, et un critère activé. Le score composite est une moyenne pondérée, et une moyenne compense : avec l’exécution, la couverture et l’hygiène des anomalies au maximum, un plan dont la plupart des tests échouaient — ou dont la plupart n’avaient tout simplement jamais été exécutés — pouvait encore franchir le seuil GO. Chaque barème porte désormais un plancher de taux de réussite et un plancher de taux d’exécution, tous deux calés sur son propre seuil GO (0,85 Strict · 0,75 Standard · 0,65 Rodage) : aucun nombre nouveau à retenir. Sous l’un ou l’autre, le verdict est NO-GO et la note est plafonnée à C. Un cas marqué Non applicable n’est pas un cas non exécuté — sortir volontairement quelque chose du périmètre ne coûte rien. Un rapport sans aucun test exécuté reste non évalué, jamais un E.Le critère échec sans défaut lié est désormais actif par défaut sur les trois barèmes, et son déclenchement plafonne également la note à C. L’hygiène des anomalies n’a jamais compté que les bugs déclarés : un test en échec sans bug lié obtenait un 20/20 parfait, alors que déclarer le bug correctement coûtait des points — l’incitation fonctionnait à l’envers.Le barème qui décide est maintenant visible sur le rapport. Une ligne discrète sous la note nomme le barème en vigueur et le seuil GO réellement appliqué, ce qui permet de défendre un verdict sans ouvrir les Réglages — et elle porte la réserve confiance faible quand moins de cinq tests ont été exécutés, au lieu de la garder pour elle. À l’écran uniquement : les exports PDF, Word et HTML ne gagnent aucune ligne. Le réglage du barème remonte par ailleurs en tête de la page Réglages, avec une phrase disant ce qu’il décide.Les rapports déjà enregistrés conservent leur verdict. Chacun porte le barème capturé au moment de sa génération et est relu sous celui-ci. Les rapports générés avant l’existence des barèmes projet (avant la v2.15.0) n’en portent aucun et sont relus sous le barème courant : ceux-là peuvent changer à la réouverture.Voir Quality Gate et Aide à la décision.

2026-08-30

L’historique indique désormais de quel projet vient chaque rapport. L’historique personnel est stocké par utilisateur à l’échelle de toute l’organisation : quiconque travaille sur plusieurs projets voyait tous ses rapports dans une liste indifférenciée. Une colonne Projet se place juste après le plan de test, et un filtre Projet s’intercale entre le filtre de statut et Mes rapports. Il s’ouvre sur votre projet courant, ou sur Tous les projets quand celui-ci n’a rien à montrer — une liste vide se lirait comme une perte de données. Le compteur d’en-tête passe à sur rapports dès qu’un filtre projet est actif.Les rapports enregistrés à partir de maintenant retiennent leur projet. Les plus anciens sont déduits à l’affichage des liens Azure DevOps qu’ils portent déjà — soulignés en pointillés, avec leur source au survol, pour qu’une valeur déduite n’ait jamais l’autorité d’une valeur enregistrée. Quand ni l’un ni l’autre n’est possible, les rapports sont regroupés sous Projet inconnu, une entrée à part entière avec son compte. Rien n’est écarté.Vous voyez aussi qui a partagé un rapport avant de l’approuver. Le badge Partagé vient se placer à côté du nom du plan, avec en dessous une ligne Partagé par portant les initiales et le nom ; vos propres rapports affichent Partagé par vous. Les rapports non partagés ne gagnent rien.Aucun nouvel appel Azure DevOps, aucune nouvelle permission, aucun rapport réécrit, et l’export CSV de l’historique est inchangé. Voir Historique des rapports.

2026-08-29

Charger un rapport depuis l’historique vous y amène enfin.Le clic sur Charger restaurait le rapport en mémoire et vous laissait sur l’onglet Historique, sans signe visible que quoi que ce soit s’était produit, et avec le sélecteur de plan affichant toujours ce qui s’y trouvait avant. Il ouvre désormais l’onglet Rapport avec le rapport affiché, et y replace le contexte : le plan du rapport est de nouveau sélectionné, et ses suites recochées. Une suite supprimée d’Azure DevOps depuis la construction du rapport est ignorée en silence plutôt que de provoquer une erreur. Pour un rapport consolidant plusieurs plans de test, TestPulse bascule en mode multi-plans et coche tous les plans du rapport — aucune sélection de suites n’y est restaurée, tout simplement parce que le mode multi-plans n’en propose pas. Les rapports enregistrés bien avant cette version se restaurent aussi bien : le plan et les suites sont lus dans le rapport lui-même, rien n’a eu besoin d’être migré.Et le plan que vous veniez de choisir n’est plus effacé par l’actualisation de la liste dans votre dos.Au démarrage, la liste des plans s’affiche immédiatement depuis le cache pendant que les données fraîches se chargent en arrière-plan. Cette actualisation remplaçait toute la sélection : ce que vous choisissiez pendant cette fenêtre — par une vue enregistrée, un modèle, la liste elle-même ou la première sélection automatique — était perdu en silence, et il fallait recommencer. Votre sélection est désormais conservée dès lors que le plan figure toujours dans la liste fraîche ; seule la liste est remplacée. Quand le plan a réellement disparu du projet, le comportement précédent est préservé à l’identique et la sélection est vidée.Nous avions envisagé de simplement désactiver les boutons « charger une vue » et « charger un modèle » pendant l’actualisation. Nous l’avons écarté : cela n’aurait couvert que deux des quatre façons de choisir un plan, aurait laissé cassée la plus courante — choisir dans la liste — et vous aurait bloqué pendant toute l’actualisation, la plus longue sur Azure DevOps Server, précisément là où le problème se voyait le plus.Une douzaine de libellés suivent maintenant la langue que vous avez choisie. Les boutons Annuler et OK de plusieurs dialogues, la colonne Statut de l’historique, l’écran affiché quand un onglet ne parvient pas à s’afficher et les trois messages affichés quand TestPulse ne peut pas démarrer étaient écrits en français quelle que soit votre langue ; trois libellés destinés aux lecteurs d’écran étaient écrits en anglais. Tous suivent désormais votre réglage — y compris les messages de démarrage, qui lisent votre préférence enregistrée de façon synchrone et restent traduits même quand c’est l’initialisation elle-même qui a échoué.

2026-08-29

Les exports Excel sortaient en français quelle que soit la langue sélectionnée.Un client travaillant en anglais recevait un classeur intégralement en français, sur la totalité de ses onglets — noms d’onglets, en-têtes de colonnes, libellés de KPI, jusqu’aux cellules Oui/Non. Sur les cinq formats d’export, seul Excel était touché, ce qui explique que l’anomalie ait survécu si longtemps : PDF, HTML, Word et PowerPoint étaient déjà corrects, tester l’un d’eux ne montrait donc rien.Il y avait deux causes distinctes. Le classeur de rapport recevait votre langue et l’ignorait délibérément. Le classeur du diagnostic Hygiène du Repository résolvait son dictionnaire une seule fois, en français, au chargement du module — une valeur figée au démarrage, dont dérivaient jusqu’aux noms d’onglets. Les deux résolvent désormais la langue à chaque export, et l’export CSV de l’historique suit également, en-têtes de colonnes et nom de fichier compris.Rien ne change si vous travaillez en français : le classeur que vous recevez est identique, cellule par cellule et nom d’onglet par nom d’onglet. GO/NO-GO, OK, NOK et N/A restent non traduits dans les deux langues, comme partout ailleurs dans le produit. Les noms d’onglets sont par ailleurs désormais débarrassés des caractères qu’Excel refuse et ramenés à sa limite de 31 caractères avant la construction du fichier, si bien qu’une traduction ne peut jamais faire échouer un export — et un nom déjà raccourci est reproduit exactement tel qu’il l’a toujours été, jamais « corrigé » en douce.

2026-08-19

Le bandeau de mise à jour affichait des astérisques à nu et s’étalait sur quatre lignes.Le bandeau qui annonce une nouvelle version reprenait mot pour mot la première entrée du panneau Nouveautés — un texte écrit pour la documentation, pas pour une ligne unique. La syntaxe Markdown apparaissait littéralement à l’écran, et la phrase s’étirait sur la longueur que son auteur lui avait donnée. Chaque version porte désormais une phrase courte, en texte brut, écrite spécifiquement pour le bandeau. Quand aucune n’est disponible dans votre langue, le bandeau n’affiche simplement pas de deuxième ligne, plutôt que de basculer vers l’autre langue ou vers un texte de documentation. Le panneau Nouveautés lui-même est inchangé.

2026-08-19

Le Repository ne propose plus que la source d’amorçage qui fonctionne vraiment.Amorcer l’arbre demandait jusqu’ici de choisir entre vos Area Paths et votre hiérarchie plans/suites. Sur un projet réel très chargé en plans, l’option plans/suites produisait un arbre plusieurs fois plus encombré que les mêmes Area Paths, au prix de bien plus de requêtes — et non par défaut d’implémentation : un arbre à un seul parent par dossier ne peut structurellement pas refléter des plans qui partagent leurs cas, si bien qu’accélérer ces requêtes aurait produit le même arbre inexploitable. Cette option a disparu, et le sélecteur de source avec elle : une seule option restante n’avait plus rien à choisir, le dialogue ouvre donc directement sur l’aperçu chiffré et la confirmation. Rien de ce que vous aviez déjà amorcé depuis l’une ou l’autre source n’est migré, purgé ni réécrit, et le Coverage Builder, le panneau « utilisé dans » et le scan d’orphelins continuent de fonctionner exactement comme avant.Et l’arbre respire enfin. Les quatre actions d’une ligne restent à l’écart tant que vous ne survolez pas la ligne, ne la sélectionnez pas ou ne l’atteignez pas au clavier — leur espace reste réservé, rien ne saute à leur apparition. Un nom de dossier long se tronque sur une ligne, le nom complet à portée de survol. Un séparateur glissable entre l’arbre et la liste des cas laisse choisir le partage de la largeur, ajustable aux flèches également, et mémorisé pour vous personnellement plutôt que pour tout le projet. Sans rien de sélectionné, l’arbre occupe toute la largeur au lieu de laisser un demi-écran à un panneau vide — et sélectionner un dossier restaure la largeur que vous aviez choisie, sans jamais la réinitialiser.

2026-08-19

Le hub vous dit désormais quand TestPulse a été mis à jour.TestPulse se met à jour automatiquement et, jusqu ici, rien côté produit ne le signalait. Un petit bandeau au-dessus des rapports du hub annonce la nouvelle version, avec un résumé court et un lien vers les nouveautés — affiché uniquement quand la version majeure ou mineure change, un correctif restant silencieux. Le fermer est propre à chaque utilisateur : un collègue qui le ferme ne le masque jamais pour vous, et il ne revient pas avant la prochaine version significative.Il sait aussi se taire quand il le faut. Ouvrir TestPulse pour la première fois n annonce jamais une mise à jour, et réinstaller une version plus ancienne sur un serveur n en annonce pas davantage.

2026-08-18

Une session exploratoire close peut désormais porter un verdict — et il ne compte volontairement pour rien.Réussi, Échoué ou Bloqué, choisi à la clôture, facultatif, sans présélection : le passer clôt la session exactement comme avant. Le verdict s’affiche comme son propre badge dans le hub, à côté du badge de statut et jamais à sa place, et un nouveau filtre Verdict restreint la liste — y compris aux sessions qui n’en portent aucun, ce qui est une réponse distincte de « tous ». La même valeur est posée en tag sur la tâche de suivi, pour être requêtable depuis Azure DevOps.Trois limites, énoncées franchement parce que le vocabulaire est emprunté aux résultats de test et suggérerait sinon l’inverse. Le verdict est définitif une fois la session close. Il n’entre jamais dans les indicateurs du rapport ni dans le quality gate — une session marquée Échoué n’incrémente aucun compteur d’échec, par décision et par test. Et le tag sur la tâche est un miroir informatif : si quelqu’un le modifie à la main dans Azure DevOps, c’est le document de session que TestPulse lit.

2026-08-18

Le flou vous montre enfin le flou.L’éditeur d’annotation traçait un cadre en pointillés et n’appliquait le vrai flou qu’au moment d’attacher la capture : vous validiez un masque que vous n’aviez jamais vu. La zone floutée est maintenant rendue en direct, par le peintre exact qui produit l’image finale — ce que vous vérifiez est ce qui sera attaché. Le cadre en pointillés subsiste comme repère pendant le tracé, tant que le bouton reste enfoncé. Rien ne change sur le moment où le flou est gravé : il reste destructif à l’attachement, et les pixels d’origine ne quittent toujours pas votre poste.Et la frise d’une session n’est plus en ajout seul. Corrigez le texte ou le type d’une note, rectifiez une légende, retirez une entrée que vous ne vouliez pas garder — tant que la session est active. Supprimer retire la référence de votre session ; la pièce jointe, elle, reste dans Azure DevOps, et la confirmation le dit plutôt que de laisser croire à un nettoyage que TestPulse n’effectue pas. Les entrées traçant un bug, une tâche ou un cas de test réel ne sont ni modifiables ni supprimables — ils existent dans Azure DevOps et s’y traitent. Une capture déjà transmise à l’un d’eux non plus. Une fois la session close, plus rien n’est modifiable.

2026-08-18

Le hub distingue désormais votre propre session active de celle d’un collègue — et cesse de promettre une reprise qu’il ne pouvait pas tenir.Une session active n’a pas encore de tâche de suivi : elle s’affichait donc « Testeur non identifié », avec le même lien quel que soit son auteur. L’appartenance se règle maintenant en comparant directement les identifiants de compte, confrontés à la valeur exacte inscrite à la création de la session — jamais un nom d’affichage, l’écart précis qui avait rendu le filtre de la 2.57.0 silencieusement inopérant. Trois issues, jamais un booléen : votre session porte votre nom et propose de la reprendre ; celle d’un collègue ouvre seulement la fiche, Azure DevOps ne restaurant une session qu’au compte qui l’a démarrée ; et quand l’appartenance est indéterminable, le lien reste neutre plutôt que de trancher.L’historique exploratoire d’une exigence n’est plus invisible depuis sa propre fiche. Ouvrir l’onglet Explore sur une exigence explorée trois fois n’affichait que « Aucune session exploratoire active » — vrai du présent, faux du passé. Les sessions closes y sont désormais listées, chacune renvoyant à sa tâche de suivi, le formulaire de démarrage restant à sa place. Dans l’onglet Test coverage, l’analyse de profondeur gagne une ligne informative indiquant leur nombre et nommant l’onglet Explore — jamais un avertissement, et sans toucher à la pastille de couverture : une session exploratoire n’est pas un cas de test, et lui créditer de la couverture gonflerait un chiffre indéfendable.Les captures peuvent dire ce qu’elles montrent. Marquez une capture comme une étape à réaliser ou un résultat obtenu — au moment de la prise, quand vous savez encore pourquoi vous l’avez faite, et modifiable ensuite depuis la frise. La génération d’un cas de test respecte alors l’ordre de la frise : chaque note ouvre une étape, et les captures qui la suivent se rattachent à cette étape plutôt qu’au work item en général. Une capture marquée « résultat » renseigne le résultat attendu de l’étape avec « Voir copie d’écran » et en fait une étape de validation, comme Azure DevOps distingue lui-même les deux. Une session sans aucun marquage produit exactement le cas de test qu’elle produisait avant.

2026-08-18

L’indicateur « Découvertes » du hub est retiré — de l’écran comme du rapport PDF consolidé.Il additionnait les work items créés depuis une session. Un testeur qui saisit les mêmes constats directement dans Azure DevOps comptait zéro : le nombre n’a jamais mesuré ce que son nom promettait. Supprimé plutôt que rebaptisé en quelque chose d’exact mais toujours sans valeur. Un compteur de sessions prend sa place à l’écran — celui-là correspond aux lignes réellement affichées, sessions incomplètes comprises, donc vérifiable en les comptant. Le tableau de synthèse du PDF perd simplement la ligne.Une session active se rouvre désormais directement depuis le hub, par un lien vers sa propre fiche où l’onglet Explore la reprend.Pour que ce lien soit seulement atteignable, les sessions sans tâche de suivi — c’est-à-dire toutes les sessions actives, la tâche n’étant créée qu’à la clôture — échappent maintenant au filtre Testeur. Sans cela, la vue « mes sessions » introduite en 2.57.0 aurait masqué précisément celles pour lesquelles ce lien existe. Tous les autres filtres continuent de s’y appliquer.

2026-08-18

Le filtre « mes sessions » livré la veille ne s’appliquait jamais.Le hub lisait l’adresse e-mail du compte, et la comparait à des noms de testeur résolus depuis la tâche de suivi de chaque session. Les typings du SDK installé sont sans ambiguïté — un champ porte l’e-mail, l’autre le nom d’affichage — donc aucune correspondance n’était possible, et le filtre restait vide à chaque fois, indiscernable du cas d’un utilisateur n’ayant réellement aucune session.Une ligne a changé. Aucun repli sur l’autre champ n’a été ajouté : une adresse e-mail n’est jamais une clé valide ici, et un repli aurait échoué silencieusement au lieu de laisser le filtre vide — le comportement correct quand un nom ne peut pas être résolu.La régression était invisible aux tests parce que le mock portait la même hypothèse fausse que le code : un seul champ, contenant un nom d’affichage. Il porte désormais les deux, distincts, de sorte qu’un test échoue si le mauvais est relu un jour.

2026-08-17

Le hub Explore s’ouvre désormais sur vos propres sessions au lieu de lister tout le projet à chaque visite.Chez le client de référence, un projet Azure DevOps unique regroupe toutes les équipes : ouvrir le hub revenait à voir les sessions de tout le monde et à filtrer à la main. Le filtre Testeur se positionne maintenant sur votre nom résolu — appliqué exactement une fois, au moment où arrivent les métadonnées dont il dépend, et jamais ensuite : un drapeau empêche qu’il revienne après que vous l’avez retiré ou changé. Aucune session résolue à votre nom, ou identité indisponible : le filtre démarre vide, exactement comme avant, plutôt qu’actif sur une valeur qui ne correspond à rien.Une puce visible « Filtré sur mes sessions » figure à côté des filtres, retirable en un clic — jamais enfouie comme valeur pré-sélectionnée dans une liste déroulante, que personne ne remarquerait et qui vous laisserait conclure que personne d’autre n’explore.

Ce filtre réduit le bruit ; il n’apporte aucune confidentialité. Les sessions exploratoires sont stockées au scope projet, lisibles par toute personne ayant accès au projet, indépendamment des équipes Azure DevOps. La page Confidentialité le dit désormais en clair.

2026-08-17

Clôturer une session exploratoire n’oblige plus à retourner dans Azure DevOps pour affecter la tâche qui vient d’être créée.Un petit dialogue s’ouvre désormais juste après la confirmation de fin de session, et propose deux choses : à qui revient la tâche de suivi, et dans quel état elle démarre. Le champ d’affectation réutilise la même recherche d’identités que les contacts du rapport, et reste saisissable quand cette recherche n’est pas disponible — sur certaines installations on-premises, elle ne l’est simplement pas. La liste des statuts est lue depuis les catégories d’état de votre propre type de work item, jamais depuis un nom codé en dur : si votre processus dit « Terminé », c’est « Terminé » qui s’affiche. La catégorie Removed est systématiquement exclue — proposer « supprimer » comme statut de clôture est un piège, et irréversible dans certains processus. Si votre processus n’a aucun état de catégorie terminale, rien n’est présélectionné plutôt qu’une valeur devinée.Il y a un bouton Passer, et c’est la partie qui comptait le plus. Le passer ne produit pas une tâche légèrement différente : il produit un patch octet pour octet identique à celui construit avant l’existence de cette fonctionnalité, vérifié par un test dédié. Une étape facultative qui modifierait discrètement vos données ne serait pas facultative.Si votre processus refuse la transition demandée, la tâche est quand même créée et la session se clôt exactement comme avant. Un avertissement distinct et non bloquant nomme ce seul échec — avec le message d’Azure DevOps lui-même plutôt qu’un « échec de la mise à jour » générique —, et la transition n’est jamais rejouée : une règle de processus n’est pas un aléa réseau.

2026-08-17

Un cas de test créé depuis une session exploratoire apparaissait comme « Testé par » son exigence au lieu de la « Tester ».Azure DevOps interprète un lien du point de vue du work item que l’on modifie — ici le cas de test. La relation désormais émise le fait lire dans le bon sens. Les liens existants ne sont pas réécrits : seuls les nouveaux changent, et l’aide embarquée le dit, plutôt que de vous laisser vous demander pourquoi anciens et nouveaux work items divergent.Deux autres points sur ce même panneau. Les fichiers déposés sur la frise de session n’avaient aucune case à cocher — seules les captures étaient proposées à l’attache, alors que ces fichiers étaient déjà téléversés et leur URL déjà connue. L’écart venait de la collecte du panneau, pas de ce qu’il construisait. Captures et fichiers sont maintenant proposés à l’identique.Et le panneau est disponible après la fin d’une session, plus seulement pendant. Rouvrez la tâche de suivi de la session et le même geste s’y trouve, en relisant la session close depuis le stockage. Une pièce qui ne peut pas être attachée s’affiche désormais grisée avec sa raison, au lieu de disparaître silencieusement de la liste.

2026-08-17

Générer un rapport sur un plan de test entier pouvait échouer sur Azure DevOps Server — jamais dans le cloud.Mesuré sur une instance on-premises réelle : demander à un lot de work items d’ignorer les identifiants morts ne les ignore pas. Il renvoie null à leur place, et les compte. Le cloud, lui, les omet réellement — ce que le code supposait. Les suites importées d’anciens plans requirement-based conservent des identifiants d’exigence orphelins qui ne résolvent plus ; cocher toutes les enfants d’une suite parente vide fait entrer les identifiants orphelins de la parente dans le lot, et cela suffisait à arrêter tout le rapport.Corrigé à la source plutôt qu’à l’endroit où ça cassait, de sorte qu’aucun des vingt appelants de cette primitive ne peut recevoir de null, quel que soit le chemin qui répond. Deux autres lots indépendants de l’onglet Couverture d’une fiche portaient le même défaut latent et ont été corrigés avec. Rien ne change quand tous les work items existent — l’immense majorité des cas, et la totalité du cloud.En parallèle, la traçabilité gagne un périmètre « Suites d’exigences uniquement », à côté de « Inclure les plans inactifs ». Par défaut, elle combine toujours les suites requirement-based et les liens directs portés par les cas de test, exactement comme avant. Sur un plan de non-régression rejoué pendant des années, cette seconde source peut ramener des liens vers des exigences closes depuis longtemps, sans rapport avec la campagne en cours — l’option les écarte. Le choix est mémorisé par projet et modifiable sans quitter l’écran du rapport. Un point d’interrogation explique ce que chaque mode inclut, et pourquoi le score qualité redistribue le poids de la couverture quand il n’y a plus rien à mesurer.

2026-08-14

Chaque exécution affichée dans un rapport est désormais à un clic de l’exécution qui l’a produite.Le tableau Résultats portait une colonne « Run » qui affichait invariablement un tiret : le lien n’avait tout simplement jamais été branché. L’Historique complet montrait un numéro de run, ajouté la veille, qu’on pouvait lire mais pas suivre. Les deux affichent maintenant la même chose — le numéro de run cliquable — et ouvrent le résultat exact, pas seulement le run qui le contient. Quand l’identifiant du résultat n’est pas disponible, le lien se rabat sur le run plutôt que d’en inventer un.Ces liens sortent désormais par la même porte que partout ailleurs dans le produit. Sur Azure DevOps Server, l’extension s’exécute dans un cadre isolé où un lien « nouvel onglet » ordinaire ouvre une page blanche ; le rapport en utilisait encore un à trois endroits, dont le panneau des tests en échec sans défaut tracé. Les trois délèguent maintenant à l’hôte : un nouvel onglet s’ouvre en on-premises comme dans le cloud. Le clic droit continue de fonctionner comme attendu.

2026-08-14

L’Historique complet indique désormais de quelle exécution vient chaque ligne — et un rapport résiste à une comparaison côte à côte avec Azure DevOps.Ouvrir le même cas de test dans les deux outils pouvait afficher neuf lignes ici et cinq là, sans aucun moyen d’expliquer l’écart. Les deux avaient raison : Azure DevOps masque les exécutions qui n’ont publié aucune issue, TestPulse les conserve. Mais rien dans le rapport ne permettait de l’établir, et un chiffre qu’on ne peut pas reconstituer est un chiffre qu’il faut croire sur parole. Chaque ligne porte maintenant son numéro d’exécution, et survoler un statut None en explique le sens — l’exécution existe, Azure DevOps n’a publié aucune issue pour ce cas.Le compteur de l’onglet Tests instables suit désormais le filtre actif, comme Résultats et Historique complet. Filtrer sur un seul cas de test ne le laisse plus annoncer le plan entier.En coulisses, le garde-fou de complétude introduit au fil des versions précédentes n’a plus rien à surveiller : toutes les collections que ce produit lit ont été mesurées contre un serveur réel. Quatre paginaient, trois se sont révélées dépourvues de tout mécanisme de troncature. Le garde-fou reste en place pour ce qui sera ajouté ensuite.

2026-08-13

L’historique d’exécution d’un rapport pouvait se réduire à une seule exécution, masquant le correctif d’instabilité livré quelques heures plus tôt.Azure DevOps numérote les résultats de test par exécution, pas globalement : quatre exécutions des mêmes 300 cas portent toutes les identifiants 100000 à 100299. Le rapport utilisait cet identifiant seul pour éviter de lister deux fois le résultat courant — ce qui supprimait silencieusement la totalité des résultats historiques. Sur un plan de 1200 résultats, l’onglet Historique en affichait 300 et chaque cas déclarait une seule exécution.La déduplication s’appuie désormais sur le couple exécution + résultat. L’historique revient au complet, et le calcul d’instabilité a enfin de quoi travailler.

2026-08-13

Un test exécuté une seule fois pouvait être signalé instable à 100 %.L’instabilité était calculée sur toutes les issues enregistrées, y compris les points de test jamais exécutés. Une seule exécution précédée de l’un d’eux produisait une transition « None → Passed » — comptée comme une bascule, sur un test qui n’avait jamais varié. Sur un plan rejoué avec un passage bloqué, les 300 cas ressortaient instables.Seules les exécutions réelles comptent désormais — Passed, Failed, Blocked, Inconclusive. Blocked reste dedans : le testeur a tenté et constaté un obstacle. Il faut deux exécutions véritables pour que l’instabilité veuille dire quelque chose.Le calcul lui-même vivait en cinq exemplaires, dont deux avec un seuil codé en dur au lieu de celui configuré dans les Paramètres — si bien qu’un même rapport pouvait déclarer un test instable dans son PDF et stable dans sa notification. Il n’y a plus qu’une implémentation, un seuil, et une garde qui échoue si un sixième exemplaire apparaît.

2026-08-13

La documentation embarquée n’affiche plus de codes de développement internes.L’aide en ligne portait 198 références à des identifiants internes de fonctionnalité, dont plusieurs dans des titres de section qu’un lecteur voit en premier — « Générer un plan depuis un dossier (F-53) ». Ils ne veulent rien dire hors du code et donnaient à la documentation l’allure d’un brouillon interne oublié en production. Ils ont tous disparu, ainsi que les libellés de vague internes, et une garde échoue désormais si l’un d’eux réapparaît.L’aide documente aussi la garantie de complétude sur les résultats d’exécution, à côté de celle sur les suites.

2026-08-13

Le taux de passage pouvait être calculé sur des données partielles — l’endpoint qui porte le résultat d’exécution de chaque cas était interrogé en un seul appel, sans aucun moyen de savoir s’il avait tout renvoyé.Une troncature à cet endroit n’aurait pas masqué une ligne qu’on aurait remarquée manquante : elle aurait produit un chiffre faux, indiscernable d’un chiffre juste. Une sonde jouée sur Azure DevOps Services et sur une instance Server 2022.1 on-premises a montré des paramètres de pagination honorés à l’identique sur les deux, et un plafond serveur implicite qui existe mais n’est pas spécifié. TestPulse n’en dépend plus : les résultats sont récupérés page par page jusqu’à épuisement de la collection — ce qui reste juste quelle que soit la valeur de ce plafond, et le reste si Azure DevOps la modifie.Les suites de moins de 200 cas de test — l’immense majorité — font toujours exactement un aller-retour : rien ne charge plus lentement qu’avant. Et si les résultats ne peuvent toujours pas être récupérés intégralement, un bandeau discret et non bloquant le signale sur le rapport, avec un message distinct selon qu’on sait qu’il en manque ou qu’on n’a simplement pas pu vérifier. Jamais dans un export.

2026-08-13

L’avertissement de complétude introduit la veille pouvait affirmer que des suites manquaient alors que TestPulse n’en savait rien — et rester muet quand rien n’avait été récupéré du tout.Les deux cas s’énoncent désormais correctement. « Des suites manquent » n’apparaît que lorsqu’une perte est réellement constatée ; « l’exhaustivité n’a pas pu être vérifiée » apparaît quand elle est simplement inconnue ; et un plan dont les suites n’ont pas pu être récupérées n’est jamais présenté comme un plan vide qui aurait été vérifié. Deux situations différentes, deux messages différents, jamais confondus — parce qu’un rapport ne vaut que ce que vaut son affirmation la plus faible.

2026-08-13

Un plan de test de plus de 200 suites perdait silencieusement tout ce qui suivait la 200ᵉ — et affichait le reste dans le mauvais ordre, avec une hiérarchie disloquée.Sur un plan de 426 suites, 227 étaient absentes et rien ne le signalait : le compteur de suites se lisait comme si tout était là. Les suites étaient par ailleurs triées par ordre alphabétique au lieu de l’ordre dans lequel vous les avez rangées dans Azure Test Plans, et masquer les suites vides détachait leurs enfants en les remontant au premier niveau.Les trois sont corrigés ensemble. Les suites se chargent désormais intégralement, dans l’ordre d’affichage d’Azure Test Plans, avec leur hiérarchie native — une suite parente vide qui porte un enfant visible n’est jamais retirée, quels que soient vos filtres d’affichage. Le chargement d’un gros plan reste aussi rapide qu’avant, malgré un volume récupéré bien supérieur.Trois ajouts l’accompagnent : les suites vides sont affichées par défaut (un choix explicite de les masquer est toujours respecté), un filtre sur le nom des suites qui conserve visible chaque ancêtre d’une correspondance pour ne jamais perdre votre place dans l’arbre, et la recherche d’un plan de test par son identifiant dans le champ de recherche existant.

2026-08-12

L’onglet Explore d’une fiche de travail ne reste plus bloqué au chargement sur Azure DevOps Server 2022.1.Depuis la 2.46.0, l’ouvrir en on-premises affichait « TestPulse failed to load », et rien d’autre. Sur cette plateforme, l’onglet de fiche s’exécute dans un cadre isolé où le stockage du navigateur est indisponible, et une seule lecture non protégée de ce stockage arrêtait l’onglet avant même son démarrage. Tous les autres modules continuaient de fonctionner, ce qui est précisément ce qui rendait le défaut difficile à repérer.Votre couleur de rapport et votre logo atteignent désormais cet onglet en on-premises également, synchronisés via vos préférences Azure DevOps plutôt que par le stockage que ce cadre ne peut pas utiliser. L’onglet s’affiche immédiatement avec la charte par défaut, puis applique la vôtre un instant plus tard ; si elle ne peut pas être récupérée, un avis discret le signale plutôt que de vous laisser exporter aux mauvaises couleurs sans le savoir.Un logo trop volumineux pour se synchroniser rapidement est maintenant réduit automatiquement — vous en êtes informé — et refusé avec un message clair s’il reste trop lourd après réduction, en conservant votre logo précédent plutôt qu’en le perdant.

2026-07-31

Sessions exploratoires : un work item supprimé ne vide plus le reste de la liste.Supprimer un seul work item faisait perdre d’un coup, à tous les autres groupes de l’onglet Explore, leur titre, leur type et le nom de leur testeur : Azure DevOps rejette une lecture groupée entière dès qu’un identifiant n’existe plus, et l’onglet se repliait sur « rien » plutôt que sur « le reste ». Les identifiants morts sont désormais omis, et tous les work items encore présents se résolvent normalement. La même protection a été appliquée aux lectures groupées de couverture, qui portaient le même défaut latent.Deux correctifs de filtres arrivent en même temps. Chaque option d’un filtre porte maintenant son propre compteur de résultats, au lieu de répéter le même total générique sur toutes les entrées. Et les filtres area path et iteration path retiennent les sous-chemins : choisir une racine ramène tout ce qui se trouve dessous, comme Azure DevOps traite lui-même ces chemins — sans jamais attraper par erreur un chemin qui commencerait simplement par les mêmes lettres.

2026-07-31

Sessions exploratoires : uniquement des valeurs vraies, et des rapports à votre charte.Une session laissée ouverte affichait NaN min. Un testeur apparaissait sous la forme d’un descripteur d’identité brut plutôt que d’un nom. Et un indicateur annonçant des user stories couvertes comptait en réalité tous les types de work item, y compris les Tasks d’archivage que TestPulse crée elle-même — un chiffre qui disait autre chose que ce qu’il mesurait. Les trois sont corrigés : le nom du testeur est récupéré depuis la Task archivée lorsqu’elle existe et reste délibérément neutre sinon, les Tasks d’archivage sont signalées comme telles et exclues de la couverture, et l’indicateur est renommé honnêtement quand les types de work item ne peuvent être déterminés.L’effort total disparaît, la durée par session reste. Une session laissée ouverte une nuit produit une durée arithmétiquement exacte et pratiquement dénuée de sens ; sommée sur un périmètre, elle rendait le chiffre indigne de confiance. Plutôt que de corriger la donnée en silence, l’agrégat est retiré — le rapport agrégé compte désormais des sessions par area et par iteration, ce qu’aucune session non close ne peut fausser. La durée de chaque session reste affichée à côté de sa charte, là où un humain peut en juger.Enfin, les rapports exploratoires suivent la charte configurée dans les Réglages — libellé d’en-tête et de pied, couleur de thème, logo de page de garde — au lieu des couleurs de l’outil, et chaque export depuis le hub ouvre une boîte de dialogue avec un titre pré-rempli que vous pouvez accepter ou réécrire.

2026-07-31

Sessions exploratoires : une liste lisible, et l’onglet remonte.La première version de l’onglet hub fusionnait un work item et ses sessions sur une seule ligne : une story explorée deux fois affichait deux pastilles de statut côte à côte, sans moyen de savoir laquelle était laquelle, ni d’agir sur l’une d’elles. Les groupes se déplient maintenant en une ligne par session — statut, charte, testeur, durée, compteurs, lien vers la Task archivée — et chaque session portant au moins une entrée propose son propre bouton Exporter la session. Les statuts portent une couleur et une icône distincte, ce qui garde la liste lisible en thème sombre et pour les lecteurs daltoniens.La ligne de groupe elle-même est devenue informative — nombre de sessions, activité cumulée, date de dernière activité — avec un chevron conventionnel à la place du signe plus ambigu. Les indicateurs de périmètre remontent en tête en chiffres lisibles plutôt qu’en pastilles grises indiscernables des filtres, et l’avertissement « compteurs possiblement en retard » n’apparaît que si le périmètre contient réellement une session active. Explore passe en deuxième position dans le hub, juste après Rapport.

2026-07-31

Sessions exploratoires : un onglet hub pour retrouver toutes les sessions d’un projet, et des rapports présentables.Jusqu’ici, une session exploratoire n’était accessible que depuis le work item sur lequel elle avait été menée — pratique quand on se souvient de quelle story, inutile quand la question est qu’a-t-on réellement exploré sur ce projet ? Un nouvel onglet Explore dans le hub liste toutes les sessions du projet, groupées par work item, avec des filtres sur area path, iteration path, tag de campagne, testeur et période, plus un interrupteur pour les sessions archivées. L’onglet est strictement en lecture seule : il lit et exporte, il n’écrit jamais.Au-delà d’un seuil, les sessions anciennes quittent la vue par défaut — elles sont archivées à l’affichage uniquement. TestPulse ne supprime jamais une session : l’interrupteur les fait revenir et le total réel reste affiché.Les rapports ont été reconstruits sur les mêmes fondations que le reste de TestPulse : le rapport de session porte désormais la page de garde et la mise en page de tous les autres rapports au lieu de son habillage séparé, et un nouveau rapport agrégé de périmètre couvre tout un périmètre filtré — synthèse, sessions par area et par iteration, une section par work item, une annexe. Un rapport exploratoire n’affiche délibérément ni taux de réussite ni verdict d’exécution : le test exploratoire n’en a pas, et afficher des zéros structurels aurait induit en erreur. Ses indicateurs sont la couverture et les découvertes.En arrière-plan, le stockage des sessions a été refondu pour tenir l’historique complet d’un projet sans tout relire à chaque visite, et les sessions existantes sont migrées sans perte — rien n’est supprimé, et une session dont la clôture avait échoué est signalée plutôt que réinventée en silence. Sur la fiche work item, l’onglet Explore adopte l’identité TestPulse, hérite de l’Area et de l’Iteration de la story, et restaure une session de façon fiable après un rechargement de page.

2026-07-30

Diagnostic Hygiène du référentiel.Un référentiel de test vieillit mal : des cas se dupliquent entre équipes qui ne se parlent pas, d’autres sont créés puis jamais rédigés, certains sont planifiés sans jamais être exécutés — et rien dans Azure DevOps ne le dit. Une troisième bascule Hygiène rejoint Vue arbre et Vue plate et pose un diagnostic strictement en lecture seule : TestPulse constate, ne corrige jamais. Aucune suppression, aucune fusion, aucun nettoyage automatique, pas même sur action explicite — le vocabulaire d’action est toujours « à revoir », jamais un verbe impératif. Ce sont des indicateurs à examiner, jamais un verdict : c’est vous qui décidez.Cinq constats sont immédiats et ne coûtent aucun appel supplémentaire à Azure DevOps, car ils travaillent sur les données déjà chargées par l’onglet : cas quasi-doublons (titre et étapes strictement identiques après normalisation — un simple écart de mise en forme ne crée pas de doublon), cas au même titre mais aux étapes différentes (souvent une variante légitime, à vérifier d’un œil), coquilles vides (ni étape ni description), références mortes (cas rangés dans l’arbre TestPulse mais supprimés côté Azure DevOps) et dossiers vides. Trois constats supplémentaires demandent la lecture des plans, suites et résultats : ils vivent dans une section Analyse des plans derrière leur propre bouton, avec leur coût annoncé avant lancement. L’analyse ne démarre jamais toute seule.Chaque constat s’ouvre dans une fenêtre qui affiche son critère de détection en clair — contester un résultat ne demande pas d’ouvrir la documentation. Les doublons y sont regroupés (l’action se décide groupe par groupe, pas cas par cas), chaque cas est cliquable vers Azure DevOps dans un nouvel onglet, et « Voir dans la vue plate » bascule vers un filtre visible et réversible. Quand un constat n’a pas pu être évalué, il l’indique — jamais un zéro qui ressemblerait à un référentiel sain. Tout s’exporte en Excel : un onglet de synthèse plus un onglet par constat, et l’export porte toujours l’intégralité des lignes, même celles que l’écran ne montre pas. Le résultat est volontairement éphémère : revenir sur l’onglet repart d’une analyse non lancée, jamais d’un diagnostic périmé.

2026-07-29

Arbre du référentiel : lisibilité et pliage mémorisé.L’arbre du Repository était complet mais austère : du texte nu, aucun moyen de replier une branche, et une profondeur illisible au-delà de deux niveaux. Chaque dossier porte désormais une icône à trois états — replié en gris, déplié ou sélectionné en teal — et un chevron distinct de l’icône, pour plier sans risquer de sélectionner. Des guides d’indentation d’un pixel rattachent visuellement chaque enfant à son parent, les compteurs de cas passent en police à chasse fixe, et toutes les lignes ont la même hauteur.Surtout, les branches se replient, à la souris comme au clavier (flèches droite et gauche), et l’état est mémorisé par utilisateur : vous retrouvez votre arbre tel que vous l’avez laissé, sans replier les mêmes branches à chaque ouverture. L’arbre s’ouvre là où l’action se passe — sélectionner un dossier déplie ses parents, créer un sous-dossier dans un dossier replié le déplie. Et un dossier replié reste une cible de dépôt valide : le survoler pendant un glisser l’ouvre au bout d’un instant. Par défaut, l’arbre s’affiche replié, comme un explorateur de fichiers.« Non classés » et « Non planifiés » se distinguent enfin des vrais dossiers — icônes neutres, libellés en italique, séparateur — et rejoignent l’arbre pour former une seule navigation clavier cohérente au lieu de trois îlots isolés. « Non planifiés » n’affiche aucun compteur tant qu’aucun scan n’a eu lieu : l’absence de scan ne vaut pas zéro. Le menu « Déplacer vers… » affiche désormais le chemin complet de chaque dossier, pour ne plus confondre deux dossiers homonymes.

2026-07-28

Génération de plan guidée, progression en direct et retry honnête.Générer un plan de test depuis un dossier devient un flux guidé. Un indicateur d’étapes montre où vous en êtes (trois étapes pour un nouveau plan, deux pour une cible existante), et un bouton Précédent permet de revenir sur vos choix sans perdre ce que vous avez déjà saisi. Le nom du plan est pré-rempli depuis le dossier, et vos derniers réglages Area/Iteration Path et « reproduire l’arborescence » sont mémorisés pour la prochaine fois. Avant toute écriture, un résumé en clair détaille exactement ce qui va être créé, aux côtés d’une ventilation par couleur et libellé de ce qui est créé, réutilisé ou ignoré. Pendant l’écriture, un indicateur de progression en direct (« Création de la suite 2/4… ») remplace l’ancien figement sur les gros dossiers. Ensuite, l’écran de résultat distingue clairement succès complet et échec partiel avec des compteurs réels, donne un lien direct vers le plan, et — si des écritures ont échoué — un bouton Réessayer qui relance le flux et repasse toujours par l’aperçu avant toute nouvelle écriture. Aucune nouvelle permission Azure DevOps ; toujours en lecture seule hormis la création de plan que vous confirmez.

2026-07-27

Une toute nouvelle identité visuelle, unifiée sur tous les onglets.TestPulse adopte une identité propre : une palette teal, une typographie Public Sans et JetBrains Mono, et huit onglets enfin cohérents visuellement. Les polices sont embarquées dans l’extension — l’interface s’affiche à l’identique même sur une instance on-premises sans accès Internet, sans aucun téléchargement de police externe. C’est une refonte purement visuelle : le comportement, la navigation, les données et les appels Azure DevOps sont strictement inchangés. Un thème sombre est préparé en coulisses mais pas encore activé.

2026-07-27

Repository — générez un plan de test Azure DevOps depuis un dossier.Transformez n’importe quel dossier du Repository en plan et suites ADO réels, comme les actions contextuelles de Xray. Trois destinations : un nouveau plan (avec Area et Iteration Path, en reproduisant si vous le souhaitez l’arborescence des dossiers en suites statiques), un plan existant, ou une suite statique existante — son arbre de suites se charge à la demande, et les suites basées sur l’exigence sont affichées mais non sélectionnables puisqu’elles se peuplent par requête. Rien n’est écrit tant que vous n’avez pas confirmé un aperçu chiffré : plans et suites à créer, suites réutilisées par nom, cas à ajouter après déduplication, doublons ignorés. Le résultat est un instantané, pas un miroir — aucune resynchronisation ensuite. C’est la première capacité du Repository qui écrit dans Azure DevOps, toujours explicite et prévisualisée ; elle réutilise la permission de création de plan déjà déclarée, sans nouveau périmètre.

2026-07-25

Repository, désormais utilisable à grande échelle.

Amorcez l’arborescence automatiquement depuis vos Area Paths ou votre hiérarchie plans/suites — de façon additive et idempotente (dossiers existants réutilisés par nom, rien n’est renommé ni déplacé), avec un aperçu chiffré avant toute modification.
Opérations de masse : cochez les cas par ligne, « tout sélectionner » borné aux résultats filtrés visibles, puis affectez ou retirez un lot entier en une seule écriture atomique avec un compte-rendu exact.
Lisibilité : compteurs de cas descendants inclus par dossier, une vue plate listant chaque cas rangé avec son chemin de dossier complet, et le nœud des orphelins ADO renommé « Non planifiés » pour éviter la confusion avec « non classé ».
Ordonnancement manuel : réordonnez les cas d’un dossier par glisser-déposer ou au clavier ; triez par id, titre ou manuel — un ordre manuel n’est jamais écrasé silencieusement.

2026-07-23

Repository — correctifs de terrain (cloud).Une vraie panne WIQL fait désormais apparaître une bannière d’erreur au lieu d’un écran vide silencieux ; l’arbre ne semble plus disparaître quand la lecture de l’univers des cas échoue (les deux lectures sont désormais indépendantes) ; et la résolution d’URL WIT se replie sur une base déjà résolue sur les organisations cloud où elle pouvait échouer sans recours.

2026-07-23

Repository — fiabilisation + stockage atomique.Corrige l’arbre vide en on-premises, l’erreur au re-scan sur le cloud, le 403 WIQL / onglet vide sur le cloud, et les pannes de lecture masquées qui remontent désormais en bannière d’erreur. Le stockage passe à un document unique atomique (une lecture, une écriture par modification), et les référentiels existants sont migrés automatiquement et sans perte au premier chargement.

2026-07-22

Un nouvel onglet « Repository ».Organisez et retrouvez vos cas de test Azure DevOps dans une arborescence de dossiers gratuite et partagée au niveau projet, façon Xray, sans jamais modifier les données ADO — le Repository range des références, jamais de copies. Créez, renommez, déplacez et supprimez des dossiers à toute profondeur (glisser-déposer natif), rangez un cas via « Déplacer vers… » (équivalent clavier systématique), et cherchez par titre, id ou tag sur tout le projet. Un nœud « Non classés » est l’ensemble des cas pas encore rangés, toujours recalculé. Dépliez un cas pour voir « Utilisé dans N emplacement(s) » (plan › suite), et lancez un scan des orphelins explicite — jamais automatique — pour faire remonter les cas présents dans aucun plan. Lecture seule, aucun nouveau périmètre, aucune nouvelle dépendance.

2026-07-21

Sessions exploratoires — clôture fiabilisée + rapport PDF.Clôturer une session est désormais fiable — fini les sessions bloquées en « active » après une restauration, et les erreurs Azure DevOps sont affichées clairement au lieu d’un objet brut. Une session terminée peut être exportée en rapport PDF signé (charte, timeline complète, work items créés, captures embarquées, signature du testeur sur chaque page) en français ou en anglais ; un second bouton exporte toutes les sessions closes d’une US en un seul PDF. Les captures sont embarquées quand c’est possible et sinon listées par leur nom — le rapport ne casse jamais.

2026-07-20

Les liens de la fiche s’ouvrent correctement en on-premises.Sur les onglets Test coverage et Explore, les liens externes (run, cas de test, bug, plan) n’ouvrent plus une page blanche sur ADO Server 2022.1 — ils passent désormais par le service de navigation de l’hôte. La colonne « Dernière exéc. » garde un seul lien par ligne, et la navigation vers le plan reste au niveau du Scope, désormais suite-aware pour ne jamais tomber sur une page de plan vide. Aucun nouveau périmètre, aucune écriture.

2026-07-18

Couverture juste par configuration & détail des changements sur la fiche.

La « Dernière exéc. » suit désormais la configuration de l’US. Quand un même cas de test couvre plusieurs US sœurs qui ne diffèrent que par la configuration (Italie / Singapour / Corée…), l’onglet Test coverage n’affiche plus le run plus récent d’une US sœur : il résout la dernière exécution depuis la suite basée sur l’exigence de cette US. Les liens « Dernière exéc. » ouvrent le résultat exact, et chaque ligne peut ouvrir la suite exactement exécutée au lieu d’une page de plan vide. Les portées sont libellées plan · configuration quand une configuration est connue. Les US sans suite basée sur l’exigence conservent le comportement précédent.
« Modifiée après le dernier run » montre désormais ce qui a changé. Le badge gagne un bouton Afficher le détail : le déplier liste les champs métier modifiés depuis ce run — Critères d’acceptation, Description, État, Priorité, Itération, Tags, Titre — en avant → après, avec l’ajout surligné sur les champs riches, un marqueur alimente l’analyse de profondeur sur Critères d’acceptation / Description, et les pièces jointes ajoutées ou retirées. La lecture des révisions est lazy et opt-in — rien n’est chargé tant que vous ne dépliez pas.

Lecture seule de bout en bout.

2026-07-16

Sessions exploratoires — un nouvel onglet « Explore » sur la fiche.Menez une session de test exploratoire depuis l’US elle-même : charte pré-remplie, notes horodatées, et Ctrl+V pour coller une capture de n’importe quel écran ou application (applications desktop comprises). Chaque capture s’ouvre dans un éditeur d’annotation — flèche, rectangle, texte, surligneur et flou pour masquer les données sensibles — et n’est attachée à Azure DevOps qu’à la validation. Depuis la session, créez un bug, une tâche ou un cas de test avec des repro steps générés depuis vos notes ; terminer la session l’archive en Task taguée exploratory-session, portant le rapport complet et toutes les relations, requêtable nativement. Résiliente par conception : autosave débouncé, restauration automatique, reprise non destructive. Nécessite la nouvelle permission d’écriture des work items — un administrateur doit ré-approuver l’extension après cette mise à jour.

2026-07-08

Grille suite × configuration dans les exports : désormais opt-in.La grille livrée en v2.30.0 apparaissait dans les exports PDF et Word sans possibilité de la désactiver. Elle devient une section d’export à part entière, désactivée par défaut : activez-la dans Paramètres → Sections d’export → Grille suite × configuration. Le toggle est indépendant de la section Tableau des résultats, et la grille reste auto-masquée quand le plan ne déclare aucune configuration — même activée. L’onglet du rapport, sa pastille et l’alerte du Résumé sont inchangés. En savoir plus.

2026-07-04

Pack Insights. Quatre signaux déterministes, chacun dans son écran hôte — aucun nouvel écran, aucune nouvelle permission.

Couverture périmée (Dérive d’exigences) — les exigences modifiées après la dernière exécution de leurs tests liés, avec le compteur sans détour « N Passed ne prouvent plus rien », le champ modifié, des chips de filtrage et une option projet pour ignorer les changements de titre seuls. Un badge « Modifiée après le dernier run » sur l’onglet de la fiche, une colonne Périmée dans la traçabilité PDF/Word.
Quoi exécuter aujourd’hui (Cockpit) — les points restants ordonnés par un score pondéré transparent, trois profils figés (Strict / Standard / Onboarding) stockés au niveau projet, le détail du score par ligne et des liens execute en un clic.
Matrice Suite × Configuration (Rapport) — la grille complète suites × configurations avec trous assumés, des relances qui n’apparaissent que s’il y a des trous, des marquages non applicable partagés et réversibles, et la grille dans les exports PDF/Word.
Charge restante (Cockpit) — des jours-testeur sur la médiane des durées observées (fourchette P25–P75, médianes par suite), une date de fin en jours ouvrés, deux curseurs de simulation, les hypothèses toujours affichées — une estimation, pas un engagement.

2026-07-03

Aperçu des plans & liens execute — avec le Planning scan activé, le Coverage Builder montre par exigence où ses tests sont planifiés (colonne Plans), dépliable en couples plan/suite avec un lien Exécuter dans Azure DevOps et une progression n/m récupérée paresseusement. Aucun appel API supplémentaire au chargement de la table.
Tous les liens plan applicatifs ouvrent désormais la vue execute plutôt que la vue de composition.
Cockpit — burndown lisible et honnête — axe daté, légende et marqueurs ; la projection se suspend après 14 jours sans exécution ; le panneau de progression affiche toujours suites et configs ; des états honnêtes remplacent tout graphe vide.

2026-07-02

Correctifs Cockpit on-premises — les dates d’exécution sont désormais résolues sur les serveurs qui ne les exposent pas via l’API récente (repli en lecture seule), et une campagne terminée affiche sa vraie date de fin au lieu d’un graphe vide. Améliore aussi la colonne Last run et les signaux de fraîcheur on-premises.

2026-07-02

Coverage Builder — couverture sous-comptée corrigée — les liens Tested By sont résolus dans les deux sens : une story visiblement liée à plusieurs cas de test n’apparaît plus comme un faux trou sur Azure DevOps Server.

2026-07-02

Coverage Builder — le Planning scan ne boucle plus sur les gros référentiels — le scan résout la planification par cas de test (borné, dédupliqué, timeouts courts) au lieu d’énumérer tous les plans et suites de la collection. Même sémantique, utilisable à l’échelle entreprise.

2026-07-02

Lien vers cette documentation en ligne ajouté au pied de page de l’extension et au badge docs.

2026-07-02

Cockpit d’exécution — un nouvel onglet du hub : un burndown d’exécution par plan en test points (réel depuis des snapshots quotidiens, idéale rebasée, projection au rythme), un périmètre mouvant tracé honnêtement, les suites/configs en retard, une cible locale quand le plan n’a pas de date de fin, et une incitation à clôturer les campagnes qui stagnent. Lecture seule ; les snapshots vivent dans l’Extension Data — rien ne quitte votre tenant.

2026-07-02

Onglet Test coverage — navigable — les cinq colonnes se trient (persistance par fiche), la cellule Last run mène au run, et un plan cadré ouvre directement sa vue d’exécution.

2026-07-01

Onglet Test coverage — le sélecteur de portée s’affiche dès que la story est couverte, et chaque #ID de cas de test est cliquable.

2026-07-01

Correctif on-premises — les résultats de l’onglet Test coverage se résolvent correctement sur Azure DevOps Server (les tests ne s’affichent plus tous en Non exécuté).

2026-07-01

Bandeau verdict d’exécution sur l’onglet Test coverage — Réussi / Non OK / Non exécuté / Non couvert, précédence stricte, recalculé instantanément avec la portée.

2026-07-01

Sélecteur de portée de couverture sur l’onglet Test coverage — cadrez le pass/fail sur Dernière (tous plans) ou un plan précis, mémorisé par fiche, basculé en mémoire sans nouvelle lecture.

La génération de rapports et les cinq exports, la traçabilité Epic→US→TC→Bug, le Quality Gate (note A–E, verdict GO/NO-GO, profils et pondération risk-based), le widget dashboard, la Dérive d’exigences, le Coverage Builder, la profondeur de couverture, les imports, les notifications, la planification et bien plus — voir le changelog complet sur GitHub.

Prise en main

Concepts

Générer un rapport

Exports

Qualité & décision

Cockpit

Dashboard

Coverage Builder

Test Repository

Historique & collaboration

Configuration

Sur la fiche

Tests exploratoires

Sécurité

Référence

Changelog