Tester des objets et des termes
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Lisez cet article pour comprendre les objets et les termes utilisés dans les tests manuels et exploratoires.
Types d’éléments de travail spécifiques aux tests
Pour prendre en charge les tests manuels et automatisés, vous ajoutez et regroupez trois types principaux d’éléments de travail spécifiques au test : Plans de test, Suites de tests et Cas de test. Pour prendre en charge le partage de différentes étapes de test et paramètres de test, vous définissez les étapes partagées et les paramètres partagés. Ces objets sont stockés dans le magasin de données de suivi du travail en tant que types spécifiques d’éléments de travail.
Le tableau suivant décrit les types d’éléments de travail utilisés pour prendre en charge l’expérience de test Azure DevOps. Lier des éléments de travail spécifiques au test à l’aide des types de liens affichés dans l’image précédente.
Type d'élément de travail
Description
Plans de test
Sont utilisés pour regrouper les suites de tests et les cas de test individuels. Pour définir un plan de test, consultez Créer des plans de test et des suites de tests.
Suite de tests
Regroupez les cas de test dans des scénarios de test distincts au sein d’un plan de test unique. Le regroupement des cas de test permet de voir plus facilement les scénarios qui sont terminés. Lors de la création d’une suite de tests, vous pouvez spécifier l’un des trois types suivants :
- Suites de tests statiques : utilisée pour regrouper les cas de test sous une même suite de tests.
- Suites basées sur les conditions requises : sélectionnez une ou plusieurs exigences à partir d’une requête qui sont ensuite liées à la suite de tests.
- Suites basées sur des requêtes : sélectionnez un ou plusieurs cas de test qui sont ensuite liés à la suite de tests.
Conseil
Le champ Type de suite de test en lecture seule indique le type de suite sélectionné. Pour ajouter des suites de test, consultez Créer des plans de test et des suites de test.
Cas de test
Définissez les étapes utilisées pour tester le code ou une application pour le déploiement. Définissez des cas de test pour vous assurer que votre code fonctionne correctement, n’a aucune erreur et répond aux exigences métier et client. Vous pouvez ajouter des cas de test individuels à un plan de test sans créer de suite de tests. Plusieurs suite de tests ou plan de test peuvent faire référence à un cas de test. Vous pouvez réutiliser efficacement les cas de test sans avoir à les copier ou à les cloner pour chaque suite ou plan. Il existe deux types de cas de test :
- Manuel : cas de test qui définissent différentes étapes que vous exécutez à l’aide de Test Runner ou d’un autre client pris en charge.
- Automatisé : cas de test conçus pour s’exécuter dans un pipeline Azure.
Conseil
Vous pouvez créer un cas de test qui lie automatiquement à une exigence (Utilisateur Story (Agile), Product Backlog Item (Scrum), Requirement (CMMI) ou Issue (Basic) lorsque vous créez un test à partir de la carte. Pour plus d’informations, consultez Add, run, and update inline tests (Ajouter, exécuter et mettre à jour des tests inline).
Étapes partagées
Permet de partager des étapes entre plusieurs cas de test. Par exemple, les étapes de connexion et de vérification de la connexion à une application sont des étapes qui peuvent être partagées entre plusieurs cas de test. Pour savoir comment procéder, consultez Partager les étapes entre les cas de test.
Paramètres partagés
Permet de spécifier différents paramètres pour l’exécution d’une étape de test dans un cas de test. Pour savoir comment procéder, consultez Répéter un test avec différentes données.
Champs communs à tous les types d’éléments de travail spécifiques aux tests
Les champs et les onglets suivants apparaissent dans la plupart des formulaires d’élément de travail. Chaque onglet est utilisé pour suivre des informations spécifiques, telles que 
l’historique,
les liens ou 
les pièces jointes. Ces trois onglets fournissent, respectivement, un historique des modifications, une vue des éléments de travail liés et la possibilité d’afficher et d’attacher des fichiers.
Le seul champ obligatoire pour tous les types d’élément de travail est Titre. Lorsque l’élément de travail est enregistré, le système lui assigne un ID unique. Le formulaire met en évidence le champ obligatoire en jaune. Pour plus d’informations sur les champs liés aux tests, consultez Requête basée sur les champs d’intégration de build et de test. Pour tous les autres champs, consultez l’index du champ Élément de travail.
Champ
Utilisation
Entrez une description de 255 caractères ou moins. Vous pouvez toujours modifier le titre ultérieurement.
Assignez l’élément de travail au membre de l’équipe chargé d’effectuer le travail. Selon le contexte dans lequel vous travaillez, le menu déroulant répertorie les membres d’équipe ou les collaborateurs au projet.
Notes
Vous ne pouvez affecter du travail qu’à un seul utilisateur. Si vous devez affecter du travail à plusieurs utilisateurs, ajoutez un élément de travail pour chaque utilisateur et distinguez le travail à effectuer par titre et description. Le champ Affecté à accepte uniquement les comptes d’utilisateur qui ont été ajoutés à un projet ou à une équipe.
Lorsque l'élément de travail est créé, l'état est rétabli par défaut au premier état du flux de travail. À mesure que le travail progresse, mettez-le à jour pour refléter l’état actuel.
Utilisez d'abord la valeur par défaut. Mettez-la à jour au besoin lorsque vous modifiez l’état. Chaque état est associé à une raison par défaut.
Sélectionnez le chemin de zone associé au produit ou à l’équipe, ou laissez-le vide jusqu’à ce qu’il soit assigné lors d’une réunion de planification. Pour modifier la liste déroulante des zones, consultez Définir des chemins d’accès aux zones et attribuer à une équipe.
Choisissez le sprint ou l’itération au cours duquel le travail doit être terminé, ou laissez ce champ vide et remplissez-le ultérieurement, lors d’une réunion de planification. Pour modifier la liste déroulante des itérations, consultez Définir des chemins d’itération et configurer des itérations d’équipe.
Fournissez suffisamment de détails pour créer une compréhension partagée de l’étendue et prendre en charge les efforts d’estimation. Concentrez-vous sur l’utilisateur, ce qu’il souhaite accomplir et pourquoi. Ne décrivez pas comment développer le produit. Fournissez des détails suffisant pour que votre équipe puisse rédiger les tâches et les cas de test pour l’implémentation de l’élément.
Contrôles communs à tous les types d’éléments de travail spécifiques aux tests
Plusieurs contrôles apparaissent dans plusieurs éléments de travail spécifiques au test, comme décrit dans le tableau suivant. Si ces contrôles ne sont pas intéressants, vous pouvez les masquer de la disposition du formulaire d’élément de travail, comme décrit dans Ajouter et gérer des champs (processus d’héritage).
Control
Description
Déploiement
Fournit des informations sur le déploiement d’une fonctionnalité ou d’un récit utilisateur et sur l’étape à suivre. Vous obtenez un aperçu visuel de l’état d’un élément de travail, car il est déployé dans différents environnements de mise en production, ainsi que la navigation rapide vers chaque phase de mise en production et exécution. Ce contrôle est disponible à partir des plans de test, des suites de tests et des cas de test.
Développement
Enregistre tous les processus de développement Git qui prennent en charge l’achèvement de l’élément de travail. Il est généralement utilisé pour piloter le développement Git à partir d’une exigence. Ce contrôle prend en charge la traçabilité, fournissant une visibilité sur toutes les branches, validations, demandes de tirage et builds associées à l’élément de travail. Ce contrôle est disponible à partir des plans de test, des suites de tests et des cas de test.
Travail connexe
Contrôle utilisé dans les plans de test, les suites de tests et les cas de test pour afficher ou lier à d’autres éléments de travail tels que les exigences et les bogues, généralement via le type de lien associé .
Cas de test
Contrôle utilisé dans les étapes partagées et les éléments de travail paramètres partagés pour indiquer ou lier à des cas de test.
Personnaliser les types d’éléments de travail spécifiques aux tests
Pour le processus hérité, vous pouvez personnaliser les plans de test, les suites de tests et les cas de test. Pour le processus XML local, vous pouvez personnaliser tous les types d’éléments de travail spécifiques au test. Pour plus d’informations, consultez Personnaliser les objets de suivi de travail pour prendre en charge les processus de votre équipe.
Autorisations requises pour modifier les éléments de travail
Il existe un certain nombre d’autorisations qui contrôlent les fonctionnalités sélectionnées pour l’affichage, la modification ou la suppression d’éléments de travail. Celles-ci incluent celles répertoriées dans le tableau suivant.
Remarque
L’autorisation Modifier le type d’élément de travail ne s’applique pas aux éléments de travail spécifiques au test. Même si vous choisissez cette fonctionnalité dans le formulaire d’élément de travail, la modification du type d’élément de travail n’est pas autorisée.
Permission
Niveau
Tâche
Afficher les exécutions de test
Créer des exécutions de test
Supprimer les exécutions de test
Niveau projet
Pour afficher, créer ou supprimer des exécutions de test, vous devez disposer de l’autorisation correspondante.
Gérer les configurations de test
Gérer les environnements de test
Niveau projet
Gérez les configurations de test ou les environnements de test, vous devez disposer de l’autorisation correspondante.
Créer une définition de balise
Niveau projet
Ajoutez de nouvelles balises aux éléments de travail basés sur des tests.
Supprimer et restaurer des éléments de travail
Niveau projet
Supprimez les éléments de travail spécifiques au test et restaurez-les à partir de la Corbeille.
Supprimer définitivement le ou les éléments de travail
Niveau projet
Supprimez définitivement les éléments de travail spécifiques aux tests du magasin de données.
Afficher les éléments de travail dans ce nœud
Modifier les éléments de travail dans ce nœud
Chemin de zone
Afficher ou ajouter ou modifier des plans de test, des suites de tests, des cas de test ou d’autres types d’éléments de travail basés sur des tests nécessite l’autorisation correspondante.
Gérer les plans de test
Chemin de zone
Modifiez les propriétés du plan de test, telles que les paramètres d’exécution de test et de résultat de test.
Gérer les plans de test
Chemin de zone
Créer et supprimer des suites de test ; ajouter et supprimer des cas de test des suites de tests ; modifier les configurations de test associées aux suites de tests ; et modifier une hiérarchie de suite de tests (déplacer une suite de tests).
Pour plus d’informations sur la définition de ces autorisations, consultez Définir les autorisations et l’accès pour les tests et modifier les autorisations au niveau du projet.
Exporter, importer et mettre à jour en bloc des éléments de travail spécifiques au test
Comme avec d’autres éléments de travail, vous pouvez modifier en bloc des éléments de travail spécifiques au test. Pour plus d’informations, consultez les articles suivants :
Conditions de test
Le tableau suivant décrit plusieurs termes utilisés dans les tests manuels et exploratoires.
Terme
Definition
Configuration
Spécifie l’environnement unique utilisé pour tester une application ou un code. Pour définir une configuration de test, vous définissez d’abord les variables de configuration, puis définissez la configuration de test. Pour plus d’informations, consultez Tester différentes configurations.
Variable de configuration
Spécifie un aspect unique d’un environnement de test, tel qu’un système d’exploitation, une puissance de traitement, un navigateur web ou une autre variante. Pour plus d’informations, consultez Tester différentes configurations.
Résultat
Résultat d’un point de test marqué par le testeur lors de l’exécution du test. Les options valides sont les suivantes :
- Actif (non spécifié)
- Passer un test
- Échec du test
- Bloquer le test
- Sans objet
Pour obtenir plus d’informations, consultez Répéter un test avec des données différentes. Notez que les résultats des tests de pipeline diffèrent comme décrit dans About pipeline tests.
Points de test
Les cas de test en eux-mêmes ne sont pas exécutables. Lorsque vous ajoutez un cas de test à une suite de tests, les points de test sont générés. Un point de test est une combinaison unique de cas de test, de suite de tests, de configuration et de testeur. Par exemple, si vous avez un cas de test nommé Fonctionnalité de connexion de test et que vous ajoutez deux configurations pour les navigateurs Edge et Chrome , vous avez deux points de test. Vous pouvez exécuter ou exécuter chacun de ces points de test. Lors de l’exécution, les résultats des tests sont générés. Dans la vue des résultats des tests ou l’historique des exécutions, vous pouvez voir toutes les exécutions d’un point de test. La dernière exécution du point de test est celle que vous voyez sous l’onglet Exécuter.
Paramètres d’exécution de test
Boîte de dialogue utilisée pour associer des plans de test à des pipelines de build ou de mise en production.
Paramètres de résultat de test
Boîte de dialogue utilisée pour choisir la façon dont les résultats des tests dans plusieurs suites sous les mêmes plans de test doivent être configurés.
Traçabilité
Possibilité de suivre les résultats des tests avec les exigences et les bogues auxquels ils sont liés.