Skip to main content
TestPulse ajoute un onglet « Test coverage » en lecture seule sur une fiche User Story / PBI. Il est placé automatiquement et se monte à l’ouverture de l’onglet — sans configuration, et sans jamais écrire dans vos données. Il répond à une question plus fine qu’un pourcentage de couverture : pas seulement « est-ce couvert ? » mais « est-ce que ça passe — et où puis-je creuser ? »

​
Le bandeau

En haut, deux pastilles s’affichent instantanément :
  • Couverture — des cas de test sont-ils liés, et combien ?
  • Profondeur — ces tests ont-ils de vraies étapes, ou sont-ils superficiels / sous-spécifiés ? Un signal indicatif, sans IA — jamais bloquant.

​
Verdict d’exécution

Un bandeau coloré réduit tous les résultats ci-dessous à une seule réponse :

Réussi

Tous les tests passent dans la portée courante.

Non OK

Au moins un test a échoué.

Non exécuté

Rien n’a échoué, mais certains tests n’ont pas été exécutés (Blocked / Not Applicable comptent comme Non exécuté).

Non couvert

Aucun test lié — un état neutre.
Précédence stricte : au moins un Failed donne Non OK ; sinon au moins un résultat non-passé donne Non exécuté ; seulement 100 % Passed donne Réussi (pas de « partiel »). Toujours icône + libellé (jamais la couleur seule) et ne recolore jamais la pastille Couverture — couverture et exécution restent des axes distincts.

​
Sélecteur de portée

Le sélecteur de portée s’affiche dès que la fiche est couverte — vous savez ainsi toujours que les résultats correspondent à la dernière exécution.
Choisissez la portée du pass/fail :
  • Dernière (tous plans) — par défaut.
  • Un plan · configuration précis — chaque portée est libellée avec sa configuration quand elle est connue (ex. « SPRINT 5 · QUAL_IT ») ; elle recadre statut, échecs et fraîcheur sur ce plan, et masque les tests qui n’y sont pas (avec une ligne « X sur N dans ce plan »).
Il est mémorisé par fiche, bascule instantanément en mémoire (aucune lecture nouvelle), et le verdict d’exécution se recalcule avec lui. Quand un plan précis est cadré, un lien Exécuter dans Azure DevOps à côté du sélecteur ouvre la vue d’exécution de ce plan. Couverture, Profondeur et la liste des bugs restent plan-indépendantes — un bug est lié à un cas de test, pas à un plan. Quand un même cas de test couvre plusieurs US sœurs qui ne diffèrent que par la configuration, la dernière exécution est résolue depuis la suite basée sur l’exigence de cette US — vous voyez le résultat de votre configuration, jamais le run plus récent d’une US sœur. Les US sans suite basée sur l’exigence conservent le comportement précédent (« dernière toutes configurations »).

​
#ID de test cliquables

Chaque test lié affiche un #ID cliquable qui ouvre le cas de test dans un nouvel onglet — fini la chasse dans les plans et les suites.

​
Le tableau des résultats

Pour chaque test lié : son #ID, son titre (avec son tag de type), son résultat, sa date de dernière exécution, et le bug derrière un échec — ou un indicateur échec sans défaut quand un test échoue sans bug lié. Les cinq colonnes se trient — cliquez un en-tête pour trier, re-cliquez pour inverser — et le tri est mémorisé par fiche (échecs en tête par défaut). Quand un test a un run enregistré, sa cellule Dernière exécution ouvre le résultat exact dans Azure DevOps, et chaque ligne peut ouvrir la suite exactement exécutée — jamais une page de plan vide. Une story modifiée après la dernière exécution de ses tests porte un badge « Modifiée après le dernier run » — ses résultats verts ne prouvent peut-être plus rien. Un bouton Afficher le détail le déplie pour lister 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. Voir Dérive d’exigences & couverture périmée.

​
Ce que ça ne fait pas

  • Lecture seule. Aucune écriture, aucun nouveau scope, aucune nouvelle dépendance. Le seul appel réseau supplémentaire est la lecture lazy des révisions derrière Afficher le détail — une fois, à la demande, jamais au chargement.
  • Il n’écrit jamais dans vos données et ne lit jamais les commentaires.
  • Live et indépendant des rapports publiés — il réutilise les mêmes moteurs de profondeur / statut / échec.

​
À suivre

Concepts : statuts & résultats

Comment les résultats sont lus et réduits.

Quality Gate & GO/NO-GO

Transformer les résultats en décision de release.