Démarrer une session en un écran
Depuis une US, ouvrez Explore et démarrez : une charte est pré-remplie avec le titre de l’US, avec un timer optionnel et un tag de campagne libre. Area et Iteration sont hérités de l’US et éditables via des pickers arborescents avec filtre. Au fil de la session, ajoutez des notes horodatées — elles constituent l’ossature du rapport de session et de tout bug que vous créez.Résiliente par conception
Une session est faite pour survivre à la vraie vie :- Autosave débouncé (≤ 2 s) dans l’espace de stockage de l’extension — vous ne sauvegardez pas à la main.
- Restauration automatique à la réouverture de la fiche, avec le temps écoulé recalculé.
- L’abandon demande confirmation, et une clôture en échec est non destructive et rejouable — une session n’est jamais perdue en silence ni laissée dans un état fantôme.
Clôturer avec un verdict — ou sans
La clôture archive la session sous forme de Task. Depuis la v2.60.0, le dialogue de clôture propose aussi un verdict facultatif — Réussi, Échoué ou Bloqué — sans présélection : le passer clôt la session exactement comme avant. Le verdict s’affiche dans le hub Explore comme son propre badge, y est filtrable, et est écrit en tag sur la Task archivée pour qu’Azure DevOps puisse le requêter. Deux choses qu’il n’est délibérément pas. Il est définitif — une session close est un enregistrement, pas un brouillon. Et il n’est compté nulle part : aucun indicateur de rapport, aucun quality gate. Le vocabulaire est emprunté aux résultats de test pour que les testeurs le lisent sans mode d’emploi ; la contrepartie est cette note, qui dit franchement ce qu’il ne fait pas. Depuis la v2.71.0, le même dialogue propose aussi une décision de passage — si la livraison peut passer au palier d’environnement suivant (TEST → QUAL → PROD par défaut, configurable par projet). Même contrat que le verdict : facultative, définitive, comptée nulle part. À la différence du verdict, elle est aussi écrite sur la fiche depuis laquelle la session a été menée, en tag et en un commentaire de discussion, pour que le comité de changement la trouve sans ouvrir TestPulse. Voir Décision de passage.Stockage Azure DevOps et export local
Les sessions sont sauvegardées automatiquement dans Azure DevOps Extension Data. Vos actions de capture, dépôt de fichier, création de bug ou de cas, clôture et décision de passage peuvent aussi écrire des pièces jointes et des work items dans Azure DevOps. Elles utilisent la permission d’écriture des work items ; lorsqu’une version ajoute cette permission, un administrateur doit approuver les nouvelles permissions de l’extension. Si elle n’est pas approuvée, un bandeau explicatif accompagne le refus d’écriture. L’export PDF est construit dans le navigateur puis téléchargé sur votre appareil. Aucun backend TestPulse ne reçoit la session, mais le fichier exporté sort d’Azure DevOps et peut ensuite être partagé par vos soins. Voir la matrice des actions pour distinguer sauvegardes, créations et exports.Voir aussi
Capturer, annoter & créer
Collez une capture, annotez-la, créez un bug.
Rapport de session
Exportez un PDF signé de la session.
Permissions
Le périmètre d’écriture des work items, et quand il sert.
Confidentialité
Stockage, visibilité et fichiers exportés.