Skip to main content
Le cœur d’une session exploratoire, c’est transformer ce que vous voyez en quelque chose d’actionnable : un écran capturé, annoté, attaché — et, quand c’est un défaut, un bug dont les repro steps sont déjà écrits.

​
Coller une capture de n’importe quel écran ou application

Appuyez sur Ctrl+V pour coller une capture de n’importe quel écran ou application — prenez-la avec Win+Maj+S, qui fonctionne aussi pour les applications desktop, sans rien à installer. Les fichiers distincts (une vidéo Win+G, un log…) se joignent par glisser-déposer ou via le bouton Parcourir…, qui ouvre le sélecteur natif. La zone de dépôt porte une icône, un titre et ce bouton ; pendant que vous glissez un fichier, tout le panneau de frise devient la cible, si bien que lâcher n’importe où sur lui fonctionne. Un fichier lâché à côté du panneau est avalé — le navigateur ne l’ouvrira pas dans l’onglet en faisant disparaître votre session. Aucun filtre de type n’est appliqué : la limite de taille est celle d’Azure DevOps. Plusieurs fichiers peuvent être déposés d’un coup. Ils partent l’un après l’autre, avec une ligne de progression indiquant le rang, le total et le nom du fichier en cours. Si l’un est refusé, les autres restent joints et le message nomme celui qui a échoué, avec le libellé d’Azure DevOps — rien n’est annulé.

​
Annoter avant l’attachement

Chaque capture s’ouvre dans un éditeur d’annotation : flèche, rectangle, texte, surligneur, et un flou pour masquer les données sensibles. Depuis la v2.59.0, la zone floutée est rendue en direct pendant que vous la dessinez, par le peintre exact qui produit l’image finale — vous vérifiez le masque avant de le valider, au lieu de vous fier à un cadre en pointillés, lequel subsiste comme repère tant que le bouton reste enfoncé. Le flou est destructif à l’aplatissement — une fois appliqué et attaché, les pixels masqués sont supprimés, pas seulement cachés — ce qui est exactement ce que vous voulez pour tout ce qui est confidentiel. Vous disposez de deux couleurs explicites et pouvez annuler le dernier trait. La capture n’est attachée à Azure DevOps qu’à la validation ; annuler l’éditeur n’uploade rien.
Parce que le flou est destructif, une capture masquée quitte votre poste déjà caviardée — les pixels d’origine n’atteignent jamais Azure DevOps.

​
Créer un bug, une tâche ou un cas de test

Depuis la session, créez un work item sans quitter l’écran :
  • Bug — deux champs à remplir (titre pré-rempli avec votre dernière note, plus la sévérité) ; tout le reste est injecté, visible et éditable : les repro steps générés en HTML depuis vos notes, vos captures en cases à cocher, les liens vers l’US et la session, et la classification héritée avec un override replié.
  • Tâche et Cas de test — le même flux, avec des étapes optionnelles générées depuis vos notes.
Une capture peut aussi dire ce qu’elle montre : une étape à réaliser, ou un résultat obtenu. Le choix se fait au moment de la prise — quand vous savez encore pourquoi vous l’avez faite — et se modifie ensuite depuis la frise. Les fichiers ne sont jamais typés : la distinction n’a de sens que pour une capture d’écran. Ce choix façonne le cas de test généré. L’ordre de la frise est conservé : 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 son étape avec « Voir copie d’écran » et en fait une étape de validation — comme Azure DevOps distingue lui-même une action d’une vérification. Une capture prise avant toute note n’a pas d’étape à rejoindre : elle s’attache au work item seul. Une session sans aucun marquage produit exactement le cas de test qu’elle produisait avant. Un cas de test créé ainsi se lit comme « Tests » l’exigence — le sens qu’Azure DevOps affiche du point de vue du test lui-même. Les liens créés avant la v2.55.0 se lisent dans l’autre sens et ne sont pas réécrits : seuls les nouveaux ont changé. Les captures et les fichiers déposés sur la frise sont proposés à l’attache. Une pièce dont le téléversement ne peut pas être résolu s’affiche grisée avec sa raison plutôt que de disparaître discrètement de la liste. Depuis la v2.59.0, la frise n’est plus en ajout seul tant que la session est active : le texte ou le type d’une note, et la légende d’une capture, se corrigent sur place, et une entrée peut être retirée. Retirer une entrée la sort de votre session seulement — 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. Une entrée traçant un bug, une tâche ou un cas de test réel n’est ni modifiable ni supprimable, une capture déjà transmise à l’un d’eux non plus. Une fois la session close, plus rien n’est modifiable : la tâche archivée fait foi.
Depuis la v2.55.0, ce panneau est aussi disponible après la fin d’une session : 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.

​
Archiver la session

Terminer la session l’archive en Task taguée exploratory-session (plus votre tag de campagne), portant le rapport complet — charte, durée, compteurs, timeline — et ses relations vers l’US, les captures et chaque work item créé. Les sessions deviennent requêtables nativement dans Azure DevOps : une campagne se retrouve avec une simple requête de tag. Depuis la v2.56.0, un court dialogue propose ensuite d’affecter cette tâche et de lui donner un état initial — et, depuis la v2.60.0, un verdict facultatif pour la session elle-même : Réussi, Échoué ou Bloqué, sans présélection. Le verdict est définitif une fois la session close, et il n’est compté nulle part : il n’entre ni dans un indicateur de rapport, ni dans le quality gate. La liste des statuts provient des catégories d’état de votre propre type de work item : un processus qui dit Terminé affiche Terminé, et la catégorie Removed n’est jamais proposée. Depuis la v2.71.0, le dialogue porte aussi un bloc Décision de passage quand la session a été démarrée sur un palier d’environnement — voir Décision de passage. Les deux champs sont pré-remplis, et Passer les contourne en un clic — en produisant une tâche octet pour octet identique à celle construite avant l’existence de ce dialogue. Si votre processus refuse l’état demandé, la tâche est quand même créée et la session se clôt quand même. Un avertissement distinct et non bloquant nomme ce seul échec avec le message d’Azure DevOps lui-même, et la transition n’est jamais rejouée.

​
Voir aussi

Vue d'ensemble d'Explore

Démarrer une session et pourquoi elle est résiliente.

Rapport de session

Transformez une session terminée en PDF signé.