Skip to main content
L’onglet Couverture part d’exigences (pas d’un plan) et répond à : de quoi ai-je besoin pour tester la non-régression de ces fonctionnalités ? Il remonte les tests liés à ces exigences, signale les trous, prévisualise un plan de non-régression et — après confirmation explicite — peut créer ce plan dans Azure DevOps. Read d’abord, write ensuite : vous obtenez de la valeur avant de payer le coût d’écriture.

​
Sélectionner des exigences & lire la couverture

Sélectionnez des exigences par area path, itération, requête WIQL ou liste d’IDs — vous partez des fonctionnalités à couvrir, pas d’un plan existant. Pour chaque exigence, TestPulse résout les cas de test liés via TestedBy et la classe :
  • Couverte — au moins un test lié.
  • Trou — aucun test lié.
La composition n’utilise que le graphe de liens — aucun outcome, point ou run n’est lu, et aucune nouvelle permission n’est requise. Des cartes de synthèse résument total / couvertes / trous / tests liés.
100 % de trous est un résultat valable — un plan fait de suites vides, prêtes à remplir. Ce n’est jamais une erreur.

​
« Couverte non planifiée » (opt-in)

Un troisième état — couverte non planifiée (un test existe mais n’est dans aucun plan, on veut donc le réutiliser plutôt que le réécrire) — se trouve derrière un toggle « Scan planification » opt-in, OFF par défaut. Le scan résout la planification par cas de test lié (un lookup borné et dédupliqué par test unique, avec des timeouts courts) — il n’énumère jamais les plans de la collection et reste donc utilisable sur les gros référentiels. Si un lookup échoue, ce test est réputé planifié : le scan n’invente jamais un faux « non planifié ». L’état n’est jamais affiché sans scan réel ; sans le toggle, le cœur reste à deux états nets.

​
Où les tests sont-ils planifiés ? (colonne Plans & liens execute)

Avec le Scan planification activé, une colonne Plans montre par exigence où ses tests liés sont planifiés : le nom du plan s’il est unique, « N plans » s’il y en a plusieurs, « — » pour un trou (ou scan désactivé). Dépliez une ligne pour lister chaque couple (plan, suite) avec un lien Exécuter dans Azure DevOps ouvrant la vue execute, et une progression d’exécution n/m run récupérée paresseusement au dépliage seulement (une fois par suite, cachée en session, dégradation silencieuse — une date que le serveur ne fournit pas est masquée, jamais inventée). Le détail des plans est extrait des réponses que le scan reçoit déjà — aucun appel API supplémentaire au chargement de la table.

​
Preview & export (aucune permission requise)

TestPulse construit une spec de plan : une suite requirement-based par exigence, chacune avec ses cas de test prévus et un indicateur de trou. Une preview montre ce qui serait créé (ex. « 9 suites requirement-based, 34 cas de test »). Le bouton Exporter la spec est toujours disponible et ne requiert aucune permission — il sérialise la spec en JSON, Markdown ou CSV, de sorte qu’un responsable qualité sans droit d’écriture garde toute la valeur read. L’export reflète exactement la preview.

​
À suivre

Créer le plan dans Azure DevOps

Le seul endroit où TestPulse écrit.

Lecture seule par conception

Ce qu’il écrit, et ce qu’il ne touche jamais.