`Les Dieux du ${Code}`

Nous verrons dans ce post comment à partir d’Azure DevOps,

• Créer des tests fonctionnels manuels et y ajouter des paramètres ;
• Générer automatiquement un jeu de tests à partir de tests exploratoires libres grâce à l’extension Test & Feedback ;
• Ouvrir un bug lors de l’exécution d’un jeu de tests incluant des informations granulaires de Repro Steps.

Ce post ne couvrira pas les tests automatisés. En effet, ces derniers nécessitent au préalable la création d’un projet Coded UI dans Visual Studio. Pour de plus amples informations, vous pouvez vous référer à la documentation Microsoft https://docs.microsoft.com/en-us/azure/devops/test/run-automated-tests-from-test-hub?view=azure-devops et https://docs.microsoft.com/fr-fr/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2019 

Petite revue des différents types de tests que je peux avoir dans le cadre du développement d’une application

Il existe plusieurs types de tests qui interviennent à divers niveaux du développement d’une application.

source

Les tests manuels nécessitent qu’un « testeur » interagisse avec l’application en suivant éventuellement un scénario de tests, et qu’il s’assure que le comportement de l’application est en lien avec le résultat escompté.

Les tests manuels sont essentiellement une liste textuelle d’étapes. Le corollaire étant que leur exécution et validation nécessitent une intervention humaine. Au fil du développement de l’application et de l’implémentation de nouvelles fonctionnalités, il devient de plus en plus chronophage de lancer des tests manuels après chaque compilation. Pour s’assurer donc que le développement de nouvelles fonctionnalités ou des opérations de refactorisation n’ont pas causé des régressions ou de nouveaux bugs, je peux automatiser mes tests afin de les lancer à chaque fois que nécessaire pour m’assurer de l’intégrité de mon application.

Les tests codés de l’interface utilisateur (coded UI test) permettent la mise en place de tests fonctionnels capables d’interagir automatiquement avec l’interface utilisateur de l’application, de vérifier que le résultat escompté est conforme et ; si non, d’ouvrir un bug relatif à l’erreur rencontrée. L’ensemble de ce processus étant automatisé, il est possible d’exécuter ces tests fréquemment. En revanche, leur rédaction et leur maintien sont beaucoup plus lourds et coûteux que des tests manuels.

Les tests unitaires font partie du processus du développement intrinsèque. Ils permettent au développeur de s’assurer qu’une fonction fonctionne correctement. C’est essentiellement du code qui teste du code.

Les tests de charge sont généralement basés sur des tests de performance. Le premier vérifie la performance d’une application comme son nom l’indique, tandis que le second permet de « stresser » mon application afin de vérifier si elle est en mesure de supporter une charge importante d’utilisateurs simultanés. Pour plus de détails sur ces deux types de tests, voir mon post "Tests de charge et de performance avec Azure DevOps - Load Tests".

source

Nous allons voir à présent comment mettre en place des tests fonctionnels manuels.

Test plans

Avec Azure DevOps, je dispose d’un espace dédié pour la rédaction de mes jeux de tests, leur exécution et leur suivi.

Avec les Test Plans, je peux gérer l’ensemble de mes jeux de tests pour une itération donnée. Un Test Plan inclue mon scénario de tests, les configurations (operating systems, navigateurs), les résultats. En termes d’organisation, un Test Plan peut correspondre à un sprint par exemple dans le cadre d’un développement d’applications avec une approche Agile. Je peux donc décider de tester à l’intérieur de ce Test Plan, l’ensemble des nouvelles fonctionnalités qui sont développées au cours de cette itération.

A partir d’Azure DevOps, cliquer sur Test Plans (1) puis sur New Test Plan (2).

Renseigner le Name du Test Plan (1), le Area Path (2) et la Iteration (3) puis cliquer sur Create (4).

Configuration de tests

Mon application doit pouvoir fonctionner sur une variété de configurations matérielle et logicielle. Il est donc nécessaire que mes tests prennent en compte ces variables dans la mesure où ces configurations pourraient avoir un impact sur les fonctionnalités ou le comportement de mon application. Je peux donc configurer des environnements de tests différents en fonction d’operating systems et de navigateurs différents...

Aller sur Configurations (1), puis configurer autant d’environnements que de besoin en fonction des systèmes d’opérations et des navigateurs à partir desquels les tests seront effectués. Si je coche Assign to new test plans (2), ces configurations seront assignées à l’ensemble des Test Pans qui seront créés. Les jeux de tests seront dupliqués autant de fois qu’il y a d’environnements de tests différents qui ont été configurés. 

Test case

A partir de mon Test plan, je peux mettre en place mes Test cases ou scénarios de tests. Un scénario de tests décrit un ensemble d’interactions que je peux avoir avec mon application qui ont pour objectif de valider une fonctionnalité ou un comportement de cette dernière. Un Test case est un work item de mon usine logicielle Azure DevOps.

Je peux créer un Test case à partir de Work items (1), puis New Work Item (2), Test Case (3).

Je renseigne le nom de mon Test Case (1), l’Iteration et je peux cliquer sur Shared Steps pour inclure des étapes qui sont traditionnellement partagées entre plusieurs scénarios de tests. Un Shared Step est considéré comme un work item.

Pour ajouter un Shared Step, cliquer sur l’icône Insert Shared Steps (1) puis sur Run Query (2) pour lancer la recherche de work item ayant le type Shared Steps.

Une fois mon Shared Step ajouté, je peux le visualiser à droite de ma fenêtre comme un lien. En cliquant sur le work item, je peux visualiser le contenu du Shared Step et le gérer à ma guise.

Si je n’ai pas encore de Shared Tests, je peux en créer un, en cliquant sur l’icône Create Shared Steps (1) et en lui donnant un Name (2).

Shared steps

Les Shared Steps peuvent être utiles lorsqu’il y a des étapes partagées, répétitives donc, qu’il est nécessaire d’exécuter avant de tester une fonctionnalité. Ces étapes répétitives sont répétées dans plusieurs scénarios de tests. Ceci est le cas spécifique de l’authentification par exemple. Il peut donc être utile afin d’optimiser leur maintenance de les décrire dans des Shared Steps et de réutiliser ces Shared Steps dans plusieurs jeux de tests. Je ne rédige donc qu’une seule fois les étapes nécessaires à l’accès et à l’authentification à l’application et je peux les réutiliser à autant d’endroits que je le souhaite. Ainsi, si je dois apporter une modification au processus d’authentification, je ne le fais qu’une seule fois à un seul endroit et non pas au sein de l’ensemble des jeux de tests qui incluent cette étape. Ce Shared Step sera mis à jour automatiquement dans l’ensemble des jeux de tests qui l’utilisent.

Je peux également créer un Shared Step a posteriori en sélectionnant un ensemble de steps déjà créés et en cliquant sur Create shared steps.

Je définis l’ensemble de mes étapes partagées (1), je peux ajouter des paramètres précédés de la mention @ (2), définir la valeur de mes paramètres (3), décrire le résultat escompté (4) et éventuellement ajouter des pièces jointes.

Expected result

Cette colonne permet de renseigner les informations que le testeur devrait vérifier lorsqu’il exécute le test, telles que le résultat escompté de l’action qu’il vient de réaliser.

Attachments

Dans la colonne Attachments, je peux joindre une photo ou autre qui donnerait davantage d’informations sur ce que le testeur devrait faire ou vérifier.

Paramètres

Je peux utiliser des paramètres afin de fournir différentes valeurs à un jeu de tests. Au lieu de dupliquer un jeu de tests, je peux paramétrer un jeu unique avec plusieurs valeurs possibles. Les valeurs que je définis pour chacun de mes paramètres seront utilisées au moment de l’exécution des tests, chaque valeur correspond à une itération de jeu de tests.

Aller sur Parameters (1), cliquer sur Add shared parameter set (2), renseigner le nom des paramètres (3), puis les valeurs (4).

Repartir sur le Test case, cliquer sur Add link (1) et Choisir Existing item et référencer le add shared parameter set que l’on vient de configurer et il devrait apparaître directement (2). 

Ensuite cliquer sur Add a shared parameter set (3) et l’on devrait voir les valeurs définies apparaître comme ci-dessous.

Je peux continuer à renseigner l’ensemble des fonctionnalités que je souhaite tester en ajoutant autant d’étapes que nécessaires.

Test suite

Il existe trois différentes suites de tests dans Azure DevOps :

1. Static suite
2. Requirement-based suite
3. Query-based suite

Static suite

C’est une liste simple de scénarios de tests qui peuvent être ajoutés manuellement à un scénario.

Requirements-based test suite

Ces tests concernent n’importe quels scénarios de tests liés à des user stories, items de spécifications fonctionnelles qui sont chargés au début de chaque itération en vue d’être implémentés dans l’application au cours du sprint. Ceci permet donc de créer et d’exécuter un jeu de tests qui permet de vérifier que la fonctionnalité décrite au travers de la user story a été implémentée en conformité avec les spécifications.

La work item par défaut pour les spécifications fonctionnelles est la user story pour un projet créé avec un template basé sur la méthodologie Agile dans Azure DevOps.

Query-based suite

La Query-based suite permet de spécifier une requête dynamique de work items afin de sélectionner un Test case selon certains critères. Je peux par exemple rechercher parmi des scénarios de tests ceux qui se focalisent sur des fonctionnalités critiques développées plus tôt afin de s’assurer qu’elles n’ont pas été cassées ou que nous ne sommes pas face à une régression en raison du développement de nouvelles fonctionnalités. Je peux aussi tout simplement rechercher mon Test Case en lien avec les nouvelles fonctionnalités en cours de développement que je veux tester et le charger pour exécuter les tests.

Nous allons mettre en place une Query-based suite tests pour exécuter nos tests.

A partir de Test Plans, cliquer sur la flèche (1) puis sur New Query-based suite.

Une pop-up s’ouvre pour lancer une requête qui nous permet d’effectuer une recherche parmi les tests disponibles selon certains critères. Ajouter autant de filtre que nécessaire en cliquant sur Add new clause (1), puis cliquer sur Run query (2) pour lancer la requête, puis cliquer sur Create suite après avoir sélectionné le ou les tests qui vous intéressent.

Comme mentionné plus tôt, les tests cases que j’obtiens sont multipliés autant de fois que j’ai défini d’environnements de tests (os + navigateur).

Assigner des testeurs

Je peux assigner des testeurs pour la réalisation de mes tests, à l’ensemble de ma suite de tests (2) ou à un seul jeu de tests (1).

Exécution des tests

A partir de ma query-based suite, je fais clique droit (1) sur le test que je veux exécuter et je choisis ceux qui me conviennent. J’obtiens un résultat similaire à partir de la barre en cliquant sur Run (2).

Pour exécuter mes tests, mieux vaut avoir un écran partagé dans lequel je mets d’un côté mon jeu de tests et de l’autre mon application que je teste. Ma première étape est la Shared Steps Authentification (1) que nous avons définie plus tôt. J’ai donc deux itérations (2) pour cette étape en raison des deux parameters values (4) que nous avons définies. Je peux accéder au deuxième jeu de valeurs en cliquant sur next (3). Je coche chaque étape en fonction du comportement de l’application eu égard à la fonctionnalité que je teste (5). Si une étape échoue je peux renseigner un commentaire et logger directement un bug avec Create bug (5). Je peux aussi enregistrer mes actions (7).

Création de bugs

A quoi bon faire des tests si l’on ne consigne pas les bugs quelque part, en vue de leur résolution ?

Azure DevOps a mis à disposition une série d’outils qui permettent de tracer de manière détaillée les étapes de reproduction du bug, en outre il est également possible de joindre au bug, des captures d’écran et des vidéos explicitant au maximum le bug afin que le développeur ait l’ensemble des informations à portée de main pour procéder au débogage et à la résolution du bug.

Les informations facilement mises à disposition par Azure DevOps que l’on peut inclure dans un bug sont :

• Les informations sur la machine à partir desquelles les tests sont exécutés
• Le journal des étapes suivies par le testeur lorsqu’il a rencontré le bug
• Les informations relatives au système d’information de la machine i.e. l’os, ram, version du navigateur etc.
• Les enregistrements vidéo lors des tests

Pendant l’exécution de mes tests, je peux créer directement un bug à partir de ma fenêtre de jeu de tests. Grâce à mon extension Test & Feedback, je peux enregistrer mes actions (avec audio aussi). Lors de la création d’un bug, la ou les vidéos seront directement attachée(s). Des informations systèmes sont également incluses automatiquement, et je peux ajouter des commentaires, des captures d’écran, etc.

Pour installer l’extension Test & Feedback suivre le tutoriel suivant : https://docs.microsoft.com/en-us/azure/devops/test/perform-exploratory-tests?view=azure-devops

Puis suivre les instructions pour se connecter à son projet :

https://docs.microsoft.com/en-us/azure/devops/test/connected-mode-exploratory-testing?view=azure-devops

Quand je clique sur Create Bug, une fenêtre pop-up s’ouvre. Dans les Repro Steps (1), j’ai la reproduction des étapes ayant menées au bug. System info (2) procure les informations systèmes (os, ram, navigateur, etc.) de la machine à partir de laquelle les tests ont été faits. Et le lien (3) me permet d’accéder à la vidéo que j’ai enregistrée grâce à mon extension Test & Feedback.

En cliquant sur le lien (3), j’accède à la fenêtre ci-dessous. Je peux assigner mon bug à un membre de l’équipe (1), je peux cliquer sur mon résultat de test pour avoir davantage de détails (2) et je visualise aussi le statut de mon test (3).

Lorsque je clique sur le résultat de mon test (2), une nouvelle fenêtre s’ouvre avec un niveau granulaire de détails, j’y retrouve ma vidéo précédemment enregistrée (1).

Pilotage et suivi d’exécution des tests

Je peux visualiser mes tests prêts à l’usage ainsi que leur statut (Passed, failed) dans la section Test Plans. Chaque jeu de tests apparaît autant de fois qu’il y a d’environnements de configurations définis.

Je peux aussi décider de bloquer un test qui ne serait pas prêt à être réalisé par exemple par qu’il contiendrait des fonctionnalités qui ne seraient pas encore implémentées dans la compilation utilisée par les tests.

Dans la section Runs, je peux visualiser le résultat des tests précédents.

Exploratory testing (tests exploratoires)

Comme nous venons de le voir, les tests fonctionnels précédents se basent sur une liste de spécifications fonctionnelles que l’équipe de développement a développées. Ce sont des séries de scénarios de tests prédéfinis qui ont pour objectif de valider la bonne implémentation des spécifications.

source

Les tests exploratoires aussi appelés les tests agiles (agile testing) quant à eux, ne suivent pas un scénario écrit d’avance. Ils font appel à la créativité et au côté « explorateur » des testeurs afin de laisser libre court à son imagination pour la réalisation des tests, sans qu’il se sente entravé par un script. Il va donc explorer l’application sous divers angles pour essayer de la « casser ». Il pourrait ainsi découvrir des bugs, pour lesquels nul n’aurait pensé à rédiger un cas de test.

Avec Azure DevOps, je peux réaliser mes Exploratory testing au travers de l’extension Test & Feedback que j’ai ajoutée sur mon navigateur. 

A partir du navigateur cliquer sur l’extension Test & Feedback (1); puis sur Start session (2). Ensuite, cliquer sur Record Screen (3) puis sur Start Recording et sur Share pour accepter de partager son écran. L’enregistrement de l’écran est activé.

Je peux alors laisser libre cours à mon imagination pour tester mon application de la manière que je souhaite sans suivre un scénario de tests précis.

A partir de cette fenêtre de commande, je peux faire des captures d’écran que je peux annoter (1), ajouter une note (2), lancer un enregistrement vidéo avec ou sans audio (3), créer directement un bug, une tâche ou un test case (4), accéder à mon Timeline (5) avec l’ensemble des logs (vidéos, captures d’écran, heures, etc.) ou lier un work item (6).

Si je clique sur l’icône (1), et ensuite sur Create Test Case (2), je peux transformer automatiquement mes enregistrements en Test case, scénario de tests (3). Ceci créera automatiquement un work item Test case dans mon Azure DevOps.

Conclusion

Nous avons vu comment mettre en place des tests fonctionnels avec ou sans paramètres et comment à partir de tests exploratoires, générer automatiquement un jeu de tests. Nous avons également vu comment tracer de manière granulaire les actions qui ont précédé la rencontre d’une anomalie afin d’ouvrir directement un bug aussi détaillé que possible pour une meilleure compréhension et prise en charge par les développeurs.

Il est possible également d’ajouter à ses tests plans des tests automatisés. Ceci étant, comme évoqué plus haut, les tests automatisés sont plus lourds à rédiger et maintenir. Leur mise en place doit préalablement se faire dans Visual Studio.