The Future of AI in Enterprise: How Agentic Systems Are Transforming Work
Artificial Intelligence (AI) is no longer a distant dream; it's...
Documenting Azure DevOps Test Plans
Élaborer vos documents pour vos plans de test Azure DevOps en tant qu’analyste d’affaires ou chef de test peut être une tâche intimidante.
C’est la même chose pour les exigences qui se trouvent dans votre projet Azure DevOps, mais Azure Test Plans pose un défi unique.
Dans cet article, vous obtenez un bref aperçu de ce qu’est le module Azure DevOps Test Plans, de son fonctionnement et de la façon dont vous pouvez documenter facilement vos résultats de test. Vous apprendrez aussi l’architecture même d’Azure DevOps.
Pour un aperçu rapide, vous pouvez passer directement à la vidéo
Qu’est-ce que les plans de test Azure DevOps?
Azure Test Plans est un module de gestion de tests au sein d’Azure DevOps qui permet aux utilisateurs de gérer des plans de test, des suites de tests et des cas de test pour tous les participants au processus de développement logiciel. En utilisant les plans de test, Azure Test Plans offre aussi une extension de navigateur pour les tests exploratoires et la collecte des commentaires des parties prenantes.
Azure DevOps (ADO) est un excellent endroit pour que votre équipe d’assurance qualité puisse élaborer ses plans de test pour un projet donné. En intégrant votre équipe de test sur la plateforme Azure DevOps, vous pouvez utiliser efficacement votre projet ADO comme votre unique source de vérité.
Vous pouvez faire en sorte que vos développeurs utilisent les dépôts et lient le travail de développement aux exigences, vos équipes d’analyse d’affaires peuvent construire des exigences et joindre des cas de test, et votre équipe QA utilise ces cas de test, ainsi que les exigences créées par l’équipe BA, pour exécuter tous vos tests.
Maintenant, les plans de test Azure DevOps peuvent être utilisés à la fois pour des tests automatisés et manuels. Mais cet article se concentre uniquement sur les tests manuels des plans de test ADO.
Test Plans est un endroit incroyable pour que votre équipe réalise ses besoins de tests manuels pour plusieurs raisons :
Rétroaction des parties prenantes
Le plus grand avantage des plans de test est de permettre à votre équipe de tests de travailler avec vos équipes d’analyse d’affaires et de développement dans le même environnement. En faisant cela, vous créez une source unique de vérité pour tous ceux qui travaillent sur un projet.
En déployant vos opérations de test manuelles à partir de là, vous pouvez interagir directement avec les cas de test déjà construits dans votre projet Azure DevOps. Ainsi, les contributions de votre équipe d’analyse d’affaires lors de la création de cas de test seront facilement intégrées à votre flux de travail de test. Cette capacité ajoute un grand avantage pour les équipes qui possèdent des BA capables de construire des cas de test pour l’équipe QA – si vous êtes un BA qui fait cela, vous verrez comment cela fonctionne plus tard dans l’article.
Fonctionnalités robustes de test manuel
Test Plans offre aussi des fonctionnalités manuelles de test extrêmement utiles pour aider vos testeurs à fournir des informations pertinentes sur le résultat ou les résultats de leurs tests, au-delà de simplement cocher une étape spécifique comme réussie ou échouée. Il offre aussi une fenêtre interactive pour marquer les résultats des étapes de test individuelles, capturer des captures d’écran ou des enregistrements en direct, et fournir des commentaires directement liés à l’exécution de ce cas de test.
Ainsi, lorsque vous examinez les essais que vous avez réalisés, vous pouvez identifier ce que votre testeur a vécu lorsqu’il a marqué une étape de test individuelle comme bloquée ou échouée. Ce niveau de compréhension signifie que même une équipe externe de tests manuels peut contribuer de manière réfléchie et permettre aux équipes d’identifier et d’interpréter facilement les échecs.
Extensibilité facile
Avec les bons outils de gestion de cas de test, vous pouvez générer des rapports intelligents et des matrices de traçabilité horizontale sur les détails des plans de test, suites de tests, cas de test, exécutions de cas de test et étapes de cas test.
Des outils comme celui-ci peuvent modifier la fonctionnalité des plans de test pour refléter la façon dont les entreprises gèrent les cas de test grâce au lien virtuel.
Comment fonctionnent les plans d’examen?
Chaque mois, Google reçoit des milliers de recherches demandant comment fonctionnent les tests ADO. Une raison pourrait être que la plupart des équipes utilisent des solutions propriétaires et internes, conçues pour les tests, distinctes des plans de test ADO.
Avant de comprendre comment fonctionnent les plans de test ADO, il vaut la peine de connaître la terminologie pertinente. Azure Test Plans vous offre trois principaux types d’artefacts de gestion de tests :
- Plan de test : C’est un conteneur composé de configurations, de suites de tests et de cas de test que vous pouvez diviser en étapes de test partagées et utiliser des paramètres. Vous pouvez regrouper les suites de tests et les cas de test individuels. Les plans de test incluent des suites de tests statiques, des suites basées sur les exigences et des suites basées sur des requêtes.
- Suite de tests : Il s’agit d’un groupe de cas de test qui étudient des scénarios distincts dans le cadre d’un plan de test global. Regrouper les cas facilite la détection des scénarios complets.
- Cas test : Il s’agit d’une ou d’une série d’étapes pour valider des parties individuelles de votre code ou de votre application déployée. En utilisant un cas de test, vous pouvez vérifier si votre code fonctionne correctement et répond aux besoins des affaires et des clients. Vous pouvez créer des cas de test avec un plan de test sans avoir besoin de créer une suite de tests.
Parfois, la terminologie peut être déroutante, car plusieurs équipes disent « plan de test » alors qu’elles veulent dire « suite de tests ».
Si votre équipe crée une suite de tests, elle doit choisir entre trois types différents de suites de tests, comme montré ci-dessous :
Plan d’examen 1 :
Les plans d’examen comprennent des suites de tests.
Les suites de tests peuvent être de trois types. Lisez chacune des suites suivantes pour voir les trois types différents.
- Suite d’essais 1
- Suite d’essais 2
- Suite d’essais 3
Suite de tests 1 – Basée sur les requis
Les suites de tests basées sur les exigences sont les plus simples et les plus traçables. Ils intègrent tous les cas de test pour une exigence donnée.
- Cas test 1
- Cas test 2
Suite de tests 2 – Basée sur les requêtes
Les suites de tests basées sur requêtes intègrent un groupe de tests de votre projet, peu importe les exigences auxquelles les cas de test sont liés.
- Cas test 3
- Cas test 4
Suite de tests 3 – Basé sur la statique
Les suites de tests basées sur la statique sont utilisées soit comme conteneurs pour regrouper d’autres suites de tests, soit pour regrouper un ensemble spécifique de cas de test.
- Cas test 5
- Cas test 6
- Suite d’essais 1
- Suite d’essais 2
Selon la suite de tests que vous créez, construire une suite de tests vous permet d’intégrer tous les cas de test que vous souhaitez tester.
Une fois que vous avez créé votre suite de tests avec leurs cas de test respectifs, vous pouvez exécuter l’ensemble de la suite, ce qu’on appelle une exécution de test.
Avant de commencer votre Test, vous devez choisir parmi trois types différents de suites de tests à exécuter : basées sur les exigences, basées sur les requêtes et statiques.
Comment choisir un type de suite de tests?
Avant de commencer votre exécution de test, vous devez choisir entre trois types différents de suites de tests à exécuter : basées sur les exigences, basées sur les requêtes et statiques. Rappelez-vous : les suites de tests (de tout type) ne peuvent inclure que des cas de test.
1) Suite de tests basée sur les exigences
Une suite de tests basée sur les exigences est une suite où vous associez vos cas de test à une exigence de définition de ses critères d’acceptation.
Créer une suite de tests basée sur les exigences intégrera tous les cas de test pour cette exigence. Lors de la création d’une suite, vous importez automatiquement tous ses cas de test associés. Vous allez simplement choisir l’Exigence.
Vous pouvez ensuite exécuter tous les tests pour cette exigence donnée et voir à chaque test pour conclure si le produit que vous développez répond pleinement à cette exigence.
Comme la création d’une suite récupère automatiquement tous les tests associés, votre équipe QA n’a pas besoin de refaire le travail de remplissage de toutes les exigences. Si vos assistants de recherche et développeurs ont ajouté les cas de test pour une exigence lors de leur création, les QA peuvent l’utiliser. C’est l’avantage d’un modèle unique de source de vérité. Vos équipes peuvent bénéficier du travail des uns et des autres.
Même si votre chef de test décide de créer plus de cas de test pour cette suite basée sur les exigences, les cas de test qu’il crée seront automatiquement liés à l’exigence elle-même. Donc, peu importe que des analystes de recherche, des développeurs ou des chefs de test ajoutent des cas de test, chaque équipe peut contribuer au même groupe d’éléments de travail.
Si vous utilisez des suites de tests basées sur les exigences, votre équipe peut créer des matrices de traçabilité qui vous montrent comment vos cas de test s’alignent avec vos exigences et si un cas de test a été réussi ou échoué pour une exigence donnée.
Avec des solutions plus avancées, vous pouvez même exporter et partager des rapports explicatifs de vos tests.
2) Suite de tests basée sur requêtes
Lorsque vous faites une requête d’élément de travail et que vous sélectionnez les cas de test à inclure dans votre suite, vous créez une suite basée sur des requêtes. Azure DevOps ajoute automatiquement tous les cas de test qui répondent à ces critères à la suite.
Quand utilisez-vous une suite de tests basée sur des requêtes?
Dans certains cas, les équipes effectuent des tests sur tous les cas de test actuellement dans chaque itération, ou effectuent des tests sur tout ce qui a une étiquette donnée, ou d’autres critères. Ces conditions ne sont pas nécessairement liées directement à une exigence donnée et vous ne pouvez les satisfaire qu’à travers une requête spécifique.
Contrairement aux suites basées sur les exigences, qui intègrent tous les tests associés à une exigence, les suites basées sur les requêtes permettent aux équipes de créer une suite de tests en utilisant n’importe quel critère disponible.
Si vous créez ce type de suite de tests, elle vous demande comment vous souhaitez intégrer les cas de test et vous permet de construire une requête ad hoc pour le faire. Cela permet d’intégrer les cas de test qui correspondent à des critères spécifiques. Il est important de noter que cela n’utilise pas les requêtes que votre équipe d’analyse d’affaires créerait dans Azure DevOps. Mais l’interface pour construire cette requête ad hoc est presque identique.
3) Suite de tests statiques
Les suites statiques sont des conteneurs logiques où tu peux ajouter tous les tests que tu veux. Ils ne sont pas liés à des exigences ou des questions.
Ils sont utiles lorsque vous devez créer plusieurs niveaux de suites de tests imbriquées. Ou vous pourriez avoir besoin d’un endroit pour créer et expérimenter des tests ad hoc.
Comment élaborer un plan de test
Les plans de test aident votre équipe à structurer la façon dont les tests sont effectués afin que votre projet respecte les normes de qualité. Vous créerez à la fois des plans de test et des suites de tests pour toutes les exigences de chaque itération ci-dessous.
Les étapes sont les suivantes :
Étape 1 :
Pour construire un plan de test appelé « Plan de test d’itération donné », allez à l’onglet Plan de test dans le panneau gauche de votre interface Azure DevOps. Sélectionnez « + Nouveau plan d’examen. »
Nommez ce plan de test « Plan de test pour l’itération 1 ».
Sélectionnez si vous souhaitez que ce plan de test spécifique soit pour un chemin de zone ou une itération donnée. Sinon, vous pouvez laisser ce vide (dans ces images d’exemple, ces deux champs sont laissés vides comme options par défaut).
Avec les plans de test établis, il est maintenant temps de créer une suite.
Étape 2 : Ajouter des suites de tests
Puisque l’objectif est de tester toutes les exigences d’une itération donnée d’un produit testées, vous ajoutez des suites basées sur les exigences.
Lors de la création d’une suite basée sur les exigences, vous intégrerez des cas de test déjà existants pour les exigences données. Sinon, vous devrez ajouter de nouveaux cas de test à une exigence avant de l’ajouter à une suite de tests basée sur des exigences.
Nous ne voulons pas introduire des exigences, nous voulons intégrer les cas de test associés aux exigences. Ce point est juste un rappel que même lorsque vous construisez une suite basée sur les exigences, vous créez un groupe de cas de test, pas d’exigences.
Alors, créons des suites de tests (groupes de cas de test) pour chacune des exigences de l’itération 1.
Étape 3 : Lancer une requête
Ci-dessus, vous pouvez voir la requête que vous devrez construire pour intégrer les exigences de l’Itération 1, puis vous pouvez simplement cliquer sur « Exécuter la requête » comme montré ci-dessus.
Lorsque vous lancez la requête et voyez vos éléments de travail de l’Itération 1, sélectionnez-en quelques-uns.
Puisque chaque élément de travail ci-dessus est une exigence fonctionnelle et que vous avez choisi de créer des suites basées sur les exigences, vous créerez quatre suites de test, une pour chaque exigence.
Voyons le résultat en cliquant sur le bouton bleu « Créer des suites » ci-dessus.
Sur l’image ci-dessus, vous voyez que les suites de tests pour les éléments de travail 306 et 307 ont des chiffres entre parenthèses à côté. Ils représentent le nombre de cas de test qu’ils contiennent, un et trois respectivement.
Gérer votre premier plan d’examen
Maintenant que vous avez une suite de tests pour toutes les exigences nécessaires, vous pouvez soit exécuter les tests, soit ajouter des cas de test pour compléter les suites de tests pour ces exigences.
L’action consistant à « exécuter le(s) cas(s) de test » sur une suite de tests pour voir s’ils réussissent ou échouent est appelée exécution de test. Un test est le résultat de l’exécution d’un ou plusieurs cas de test.
Faisons un test d’une de nos suites de test.
Faites un clic droit sur les cas de test dans l’élément de travail 307 et cliquez sur « Exécuter pour une application web ». Avec l’extension du navigateur Chrome, vous pouvez exécuter ces tests directement dans Chrome.
Azure ouvrira une nouvelle fenêtre pour votre Test Run (voir ci-dessous).
Si vous faites glisser cette fenêtre à côté de celle contenant l’application web que vous testez actuellement, vous pouvez voir les étapes de test individuelles et les réussir ou les échouer au fur et à mesure. Si l’application ou la fonction échoue à l’une des étapes de test, vous pouvez ajouter vos commentaires expliquant pourquoi elle a échoué.
Vous pouvez même enregistrer l’écran ou prendre des captures d’écran pour mieux illustrer l’échec. Ces informations sont maintenant jointes à l’essai d’essai.
En testant et en commentant le fonctionnement de l’application ou du produit que vous testez, vous permettez à votre équipe d’apporter des contributions significatives pour corriger les problèmes que vous avez remarqués.
Une fois que vous avez terminé un cas de test (qu’il soit réussi ou échoué), vous êtes prêt à passer au cas de test suivant dans leur test run. Pour cela, cliquez sur « suivant » comme indiqué ci-dessous.
Lorsque vous terminez votre suite de tests, vous pouvez sauvegarder et fermer votre exécution de test. Vous pourrez voir leurs résultats dans l’onglet « Runs » des plans de test DevOps d’Azure.
Comprendre les résultats du plan d’essai
Disons que vous avez exécuté le plan de test suivant (Suite de tests basée sur les exigences 307) de notre exemple ci-dessus, avec les résultats suivants :
Vous pouvez choisir d’utiliser ce même écran pour identifier ce qui a réussi et ce qui a échoué, mais si vous voulez voir les contributions de vos testeurs, vous pouvez utiliser la vue Runs sous Plans de test (voir le côté gauche de l’image ci-dessus).
Ici, vous pouvez voir le test qui « Nécessite une enquête ».
En cliquant sur Test Run, vous voyez dans « Tests récents » et vous verrez la page suivante Essai avec trois onglets. Ces onglets sont « Exécuter résumé », « Résultats de test » et « Filtre », que vous pouvez voir ci-dessous.
Les essais sont là où vous trouvez les captures d’écran, enregistrements, vidéos et/ou commentaires joints ajoutés par vos testeurs. Ils ne sont pas disponibles dans l’onglet « Résumé de la série ».
Pour voir les contributions de vos testeurs, rendez-vous dans l’onglet « Résultats du test », comme indiqué ci-dessous.
Sélectionnez votre cas de test échoué pour accéder à l’information recueillie par un testeur donné lors de son test pour ce cas de test.
Pour utiliser les retours donnés par vos testeurs, vous pouvez créer des bogues en allant à l’écran précédent, qui montre un cas de test échoué et vous permet de « créer un bogue ». Cela vous permettra de créer un bogue ayant une relation appelée « Test Result » (illustrée ci-dessous) qui renvoie directement au cas de test échoué.
Documenter votre plan d’examen
La plupart des grandes entreprises qui font un travail techniquement intensif doivent aussi documenter le travail des employés.
Vous pouvez trouver beaucoup d’informations plus approfondies concernant un échec donné d’une suite de tests individuelle, ou le plan de test dans le projet Azure DevOps lui-même. Azure DevOps vous aidera à créer un document pour votre plan de test qui inclura tous les liens vers les endroits nécessaires (comme le test montrant les détails d’un échec) à l’intérieur de votre projet.
La façon dont vous exportez les résultats d’une suite de tests donnée au format document est présentée ci-dessous.
Lorsque vous exportez ce document, vous pouvez choisir « Imprimer » pour créer un PDF qui ressemble à la capture d’écran ci-dessous :
Les liens ci-dessus vous aident à accéder à tous les détails d’un résultat donné.
Par exemple, le cas de test 1578 (trouvé près du bas de la capture d’écran ci-dessus) a la valeur « Dernier résultat du test » de « Échec » avec un lien. Ce lien vous mènera à la page des essais où vous pourrez voir les contributions de vos testeurs.
Mais cette documentation ne suffit pas. Beaucoup d’utilisateurs aiment créer la version commune d’un document de plan de test qui contient tout le contexte entourant un plan de test donné. Si vous devez créer un document qui décrit la portée, les risques, le but, la stratégie, etc., vous pourriez vouloir utiliser Microsoft Word.
La documentation n’est pas considérée comme l’une des plus grandes forces d’Azure DevOps. Mais avec une solution comme SmartDocs, vous pouvez transformer des éléments de travail, des cas de test, des suites de tests, des plans de test et beaucoup d’informations associées en documentation lisible et partageable.
La vidéo ci-dessous vous montrera comment faire.
Création de documents de test à partir d’Azure DevOps
Dans cette vidéo, nous expliquons comment vous pouvez construire la documentation entourant vos plans de test à partir de votre projet Azure DevOps en utilisant le module Smart Docs de Modern Requirements4DevOps.
Table des matières
Articles récents
What is Virtual Prototyping and Why is it Important in Product Development?
Check out this detailed guide to know about virtual prototyping,...
SOC 2 Compliance in DevOps: Managing Security Requirements Effectively
Learn more about the importance of SOC 2 compliance, its...