La qualité est un aspect vital des systèmes logiciels, et les tests manuels et exploratoires continuent d'être des techniques importantes pour maximiser cela. Dans les processus de développement logiciel actuels, tout le monde dans l'équipe possède la qualité - y compris les développeurs, les responsables, les propriétaires de produits, les défenseurs de l'expérience utilisateur, etc.
L’objectif de cet article est de partager avec vous mon retour d’expérience en tant que QA sur l’utilisation de Azure Test Plans, un service lancé avec Azure DevOps, fournissant une solution de gestion des tests basée sur un navigateur pour les tests exploratoires, manuels planifiés et d'acceptation des utilisateurs. Azure Test Plans fournit également une extension de navigateur pour les tests exploratoires et la collecte des commentaires des parties prenantes.
Azure DevOps et TFS fournissent des outils riches et puissants que tous les membres de l'équipe peuvent utiliser pour améliorer la qualité et la collaboration tout au long du processus de développement.
Les tests font partie intégrante des équipes DevOps et Agile
Une pratique courante consiste à baser les tests sur des user stories, des fonctionnalités ou des scénarios qui sont gérés sur un tableau Kanban comme dans Azure Boards. Avec les plans de test Azure, une équipe peut tirer parti des tests manuels directement depuis son tableau Kanban. Cela offre une traçabilité de bout en bout car les tests et les défauts sont automatiquement liés aux exigences et aux versions testées, ce qui vous aide également à suivre la qualité des exigences.
Ajoutez, visualisez et interagissez avec les cas de test directement à partir des cartes sur le tableau Kanban, et surveillez progressivement l'état directement à partir de la carte. Les développeurs et les testeurs peuvent utiliser cette capacité pour maximiser la qualité au sein de leurs équipes.
L’utilisation au quotidien de l’outil par les QA
Azure Test Plans offre la possibilité de lier une user story avec un test case. Consultable directement en un clic, cela présente l’avantage de n’omettre aucun comportement fonctionnel attendu par le métier.
De plus, avec Azure Test Plans, nous pouvons lier toutes les informations entre elles : user story, bug et test case.
Exemple de tests cases liés à une user story sur Azure Test Plan
Voyons un peu en détails les différentes fonctionnalités d’Azure Test Plans :
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.
Test suites
Azure devops offre trois différents types de suites de tests :
1- Static Suite :
C’est une liste simple de scénarios de tests qui peuvent être ajoutés manuellement à un scénario.
2- Requirement-based 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.
3- 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.
Test case
A partir de mon Test plan, je peux mettre en place mes Test cases ou scénarios de tests. Un Test case est un work item de mon usine logicielle Azure DevOps.
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...etc.
Shared steps
Les Shared Steps sont utiles lorsqu’il y a des étapes partagées, répétitives donc, lorsqu'il est nécessaire d’exécuter avant de tester une fonctionnalité. Ces étapes répétitives sont itérées dans plusieurs scénarios de tests. Ceci est le cas spécifique de l’authentification par exemple.
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
Je peux exécuter et choisir les tests qui me conviennent.
Si une étape échoue, je peux renseigner un commentaire et logger directement un bug. Je peux aussi enregistrer mes actions.
Création de bugs
🤔 A quoi bon faire des tests si nous ne consignons 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.
Pilotage et suivi d’exécution des tests
Je peux visualiser mes tests prêts à l’usage ainsi que leur statut (Passed, failed). 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 parce qu’il contiendrait des fonctionnalités qui ne seraient pas encore implémentées dans la compilation utilisée par les tests.
Variabilisation :
Avec l’outil Azure Test Plans, nous utilisons particulièrement la décomposition en steps et la variabilisation des informations décisives du test, le rendant ainsi dynamique. La variabilisation nous permet de tenir à jour nos tests cases directement depuis nos jeux de données, nous faisant gagner en maintenabilité.
Exemple d’un test case sous Azure Test Plan qui utilise la variabilisation
Automatisation de tests :
L’aspect qui m’a plu avec Azure Test Plans dans l’eco-système sous Azure DevOps, c’est de pouvoir lier nativement les test cases avec les tests automatisés dans Visual Studio.
Chaque test case via un trigger déclenche les tests automatisés dédiés à l’US que le QA aura liée en phase de review, et s’exécute une fois le US basculée en statut de test.
La fonctionnalité offre ainsi un gain de temps à l’équipe. Le QA peut alors se concentrer sur l’analyse des tests automatisés manquants et leurs développements.
Les tests automatisés sont plus lourds à rédiger et à maintenir. Leur mise en place doit préalablement se faire dans Visual Studio.
La communication et les dashboards
Les Dashboards d’Azure DevOps nous permettent d’intégrer des requêtes sur nos résultats de test couplés à d’autres métriques (bugs, US en cours de dev VS test réalisé). Ces boards sont visuels, dynamiques et réutilisables.
Une fois le board configuré, le gain de temps est exponentiel.
Il présente également l’atout d’être consultable par les différents intervenants du projet, sans nécessiter un compte supplémentaire. L’avantage est que ces boards sont facilement accessibles au même endroit que toutes les informations essentielles des projets (US, backlog, bugs).
Exemple d’un dashboard de résultats des tests avec Azure Test Plan
Conclusion :
Azure Test Plans est un outil qui n'est pas évident à utiliser au début, c'est en le manipulant fréquemment que nous découvrons qu'il est surprenant et riche en fonctionnalités.
- L’outil coche toutes les cases !
N’hésitez pas à l’essayer pour vos tests 😊
