UAT Azure DevOps : anomalies en work items Bug

En une minute

Regardez d'abord

Configuration de la connexion Azure DevOps, envoi d'une première anomalie comme work item, et retour du statut (68 secondes, sous-titres dans l'image).

Avant de commencer

Ce qu'il vous faut

Azure DevOps Services : une adresse du type dev.azure.com/yourcompany. (Azure DevOps Server sur vos propres serveurs n'est pas pris en charge.)
Un compte autorisé à créer des work items dans le projet où les bugs doivent arriver.
Des droits d'administrateur dans votre espace de travail UAT Studio.

Conseil : utilisez un compte de serviceLes work items sont créés au nom du compte dont vous utilisez le token. Beaucoup d'équipes utilisent pour cela un compte distinct, par exemple UAT Studio, afin que les work items ne dépendent pas d'une seule personne et soient faciles à reconnaître.

Configuration · une fois par espace de travail

Connectez votre projet Azure DevOps

Trouvez votre organisation, votre projet et votre processus

Ouvrez votre projet dans Azure DevOps et regardez la barre d'adresse : dev.azure.com/acme/Customer Portal. La première partie est l'organisation (acme), la seconde le projet (Customer Portal), exactement comme écrit, espaces compris.

Vérifiez ensuite le processus du projet : Project settings › Overview › Process.

Processus	Type de work item à utiliser
Agile, Scrum ou CMMI	`Bug` : avec Repro Steps, Severity, Priority et des tags.
Basic	`Issue` : Basic n'a pas de type Bug. Le work item reçoit le titre et la description ; Basic n'a pas de champs pour la gravité et la priorité.

Créez un personal access token

Dans Azure DevOps, cliquez sur l'icône User settings en haut à droite (le personnage avec un engrenage, à côté de vos initiales) et choisissez Personal access tokens.
Cliquez sur + New Token.
Name : UAT Studio. Organization : votre organisation. Expiration : choisissez Custom defined, jusqu'à un an.
Scopes : choisissez Custom defined et cochez Work Items › Read & write. Pour lire aussi les cas de test depuis Test Plans, cochez également Test Management › Read.
Cliquez sur Create et copiez le token. Azure DevOps ne l'affiche qu'une seule fois : gardez la fenêtre ouverte jusqu'à ce que vous l'ayez collé à l'étape 4.

Notez la date d'expiration dans votre agendaQuand le token expire, l'envoi s'arrête. Créez un nouveau token et collez-le dans UAT Studio ; rien d'autre ne change.

Ajoutez Azure DevOps dans UAT Studio

Connectez-vous sur app.uat.studio, ouvrez votre espace de travail et cliquez sur Connections. Sous Add a connection, choisissez Azure DevOps et cliquez sur Add.

Add a connection, avec Azure DevOps sélectionné et le bouton Add

Champ	À renseigner
Name	Le libellé du bouton : Send to Azure DevOps. Modifiez-le si vous connectez plusieurs projets.
Organization	La partie après `dev.azure.com/`, par exemple `acme`.
Project	Le nom du projet exactement comme dans Azure DevOps, par exemple `Customer Portal`.
Work item type	`Bug`, ou `Issue` dans un projet Basic (voir l'étape 1).
Area path	Facultatif : où vont les work items, par exemple `Customer Portal\UAT`. Vide : la zone par défaut du projet.

Cliquez sur Save settings.

La carte de la connexion Azure DevOps avec l'organisation acme, le projet Customer Portal et le type de work item Bug

Enregistrez le token

Collez le token de l'étape 2 dans le champ Personal access token et cliquez sur Store token. Le champ n'affiche ensuite que les 4 derniers caractères.

Le champ Personal access token avec un token collé, masqué par des points, et le bouton Store token

Votre token reste le vôtreLe token est envoyé une seule fois via une connexion chiffrée et stocké chiffré. Personne ne peut le relire : ni vos collègues, ni le support UAT Studio.

Testez la connexion

Cliquez sur Test connection. UAT Studio vérifie le token, le projet et l'existence du type de work item. Si tout va bien, vous voyez Connected to project … in …; work items of type Bug can be created, et OK à côté du dernier test. Si le type n'existe pas, le message liste les types dont dispose le projet.

La carte de connexion après un test réussi : dernier test OK, connecté au projet Customer Portal dans acme

Chaque journée de test

Envoyer des anomalies vers Azure DevOps

Une anomalie

Ouvrez l'anomalie. Sous Ticket in the development team's system, cliquez sur Send to Azure DevOps.

Le panneau de l'anomalie avec le bouton Send to Azure DevOps

Le numéro du work item et un lien apparaissent sur l'anomalie, et son historique indique quand elle a été envoyée et par qui. Une anomalie déjà liée ne peut pas être envoyée deux fois par erreur.

Le panneau de l'anomalie après l'envoi : liée au work item Azure DevOps 4101, avec un lien pour l'ouvrir

Toutes les anomalies après la réunion de triage

Dans Issues › Triage, prenez une décision pour chaque nouvelle anomalie. Une fois terminé, cliquez sur Send 3 to Azure DevOps (ou le nombre affiché) pour créer tous les work items d'un coup.

Ce que contient le work item

Titre : le numéro et le titre de l'anomalie, par exemple ISS-012: Quote PDF shows the wrong VAT rate.
Repro Steps et Description : ce que le testeur a écrit, le cas de test avec l'étape en échec et le résultat attendu, et qui l'a trouvée, avec un lien retour vers UAT Studio.
Severity, Priority et les tags UAT et le numéro de l'anomalie (pas dans un projet Basic).
Attachments : les captures d'écran et fichiers de l'anomalie, jusqu'à 10 fichiers de 10 Mo maximum chacun.

Fusionner les doublons

Quand vous fusionnez deux anomalies qui ont chacune un work item, le work item en double reçoit un commentaire, le lien Duplicate Of vers l'autre, et est fermé (Closed, Done ou Resolved, selon ce que le processus permet). Quand seul le doublon avait un work item, l'anomalie conservée le reprend.

Retour du statut

Quand la correction est faite dans Azure DevOps

Quand le développeur passe le work item à Resolved, Done ou Closed, l'anomalie dans UAT Studio devient Ready for retest et le testeur reçoit un email. Active, Committed ou Doing passent l'anomalie à In progress. L'état dans Azure DevOps est affiché à côté du lien.

Un nouveau test en échec n'est jamais annulé : quand le testeur rouvre l'anomalie alors que le work item est encore Resolved, UAT Studio la laisse ouverte. Une anomalie fermée reste fermée.

Automatiquement, ou immédiatement

Sans rien faire, UAT Studio consulte l'état chaque fois qu'un administrateur ouvre les anomalies, et via le bouton Update ticket status.

Immédiatement : laissez Azure DevOps prévenir UAT Studio quand un work item change, via un service hook. Vous devez être administrateur du projet dans Azure DevOps.

Dans UAT Studio, sous Connections, dans la connexion Azure DevOps, cliquez sur Create webhook address et copiez l'adresse. Elle n'est affichée qu'une seule fois.

Le retour du statut dans la connexion : l'adresse du webhook avec un bouton Copy et les étapes pour Azure DevOps

Dans Azure DevOps, ouvrez le projet et allez dans Project settings › Service hooks. Cliquez sur Create subscription.
Faites défiler la liste des services, choisissez Web Hooks et cliquez sur Next.

Nouvel abonnement service hooks : la liste des services avec Web Hooks en bas — Étape 3 : Web Hooks se trouve vers le bas de la liste.

Trigger on this type of event : Work item updated. Sous Filters, réglez Field sur State, pour que seuls les changements d'état soient envoyés. Area path et Work item type peuvent rester sur [Any], ou être limités à la zone et au type de votre projet. Cliquez sur Next.

Déclencheur : Work item updated, avec les filtres Area path, Work item type et Field réglé sur State — Étape 4 : Work item updated, Field State.

URL : collez l'adresse de l'étape 1. Laissez les autres champs (nom d'utilisateur, mot de passe, en-têtes) vides. Cliquez sur Test pour vérifier, puis sur Finish.

Action : Post via HTTP, avec le champ URL — Étape 5 : collez l'adresse dans URL.

Gardez l'adresse au sein de l'équipeL'adresse sert de clé, uniquement pour signaler les états des work items. Perdue, ou partagée par erreur ? Cliquez sur New address dans UAT Studio et mettez à jour le service hook : l'ancienne adresse cesse aussitôt de fonctionner.

Rôles

Qui peut faire quoi

AdministrateursAjoutent, modifient, testent et suppriment les connexions ; envoient les anomalies.

Testeurs, parties prenantes, développeursVoient le numéro et le lien du work item sur une anomalie. Ils ne peuvent ni envoyer d'anomalies ni voir les paramètres des connexions.

Journal d'auditChaque modification d'une connexion est enregistrée, pour que vous sachiez toujours qui a modifié quoi et quand.

Dépannage

En cas de problème

Vous voyez	Que faire
Le token n'est pas accepté, ou n'a pas accès à cette organisation	Vérifiez le nom de l'organisation (la partie après `dev.azure.com/`), que le token a été créé pour cette organisation et qu'il a le scope Work Items (Read & write). Ou créez un nouveau token et enregistrez-le à nouveau.
Le projet n'a pas de type de work item « Bug »	Le projet utilise probablement le processus Basic : renseignez `Issue` sous Work item type. Le message liste les types existants.
Introuvable (404)	Vérifiez le nom du projet : exactement comme dans la barre d'adresse, espaces compris.
Ça marchait avant, plus maintenant	Le token a probablement expiré ou a été révoqué. Créez-en un nouveau et enregistrez-le ; le reste ne change pas.
Le statut ne revient pas	Ouvrez les anomalies en tant qu'administrateur, ou cliquez sur Update ticket status. Avec un service hook : dans Azure DevOps, Project settings › Service hooks indique s'il s'est exécuté et ce qui a été renvoyé ; sous Connections dans UAT Studio, vous voyez quand le dernier message est arrivé.
Pas de bouton Send to Azure DevOps	Seuls les administrateurs le voient, et uniquement quand la connexion est On et a un token enregistré.
Les connexions ne font pas partie de votre formule	Les connexions sont incluses dans Team, Business, Partner et Enterprise, et disponibles en module pour Project. Votre administrateur peut changer de formule sous Plan & billing.

Toujours bloqué ? Écrivez à [email protected] avec le message que vous voyez. Ne nous envoyez jamais le token lui-même.

Vous utilisez Jira ? Consultez Connecter UAT Studio à Jira. Tous les guides : Aide UAT Studio.

Sécurité

Comment nous traitons votre token

Le token passe une seule fois de votre navigateur à notre serveur, via une connexion chiffrée.
Il est stocké chiffré (AES-256). La clé de déchiffrement est conservée à part de la base de données : une copie de la base seule est donc inutilisable.
Personne ne peut relire le token : ni dans l'application, ni via le support.
UAT Studio utilise le token uniquement pour tester la connexion, créer les work items que vous envoyez (avec leurs fichiers), lire l'état de ces work items et fermer un doublon après une fusion. Il n'a besoin que du scope Work Items.
Supprimez la connexion ou révoquez le token dans Azure DevOps, et l'accès prend fin immédiatement.

Connecter UAT Studio à Azure DevOps