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 viaTestedBy et la classe :
- Couverte — au moins un test lié.
- Trou — aucun test lié.
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 et export (sans droit d’écriture)
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 disponible sans droit d’écriture — 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. Les droits de lecture Azure DevOps restent nécessaires pour charger les exigences et les cas.À suivre
Créer le plan dans Azure DevOps
Créer un nouveau plan après confirmation.
Lecture seule par conception
Ce qu’il écrit, et ce qu’il ne touche jamais.