Écrit par Thomas Mazzotti
C’est quoi Xray ?
Xray est un module de Jira permettant la gestion de patrimoine de tests et l’exécution de campagne de tests. Comme beaucoup d’outil de tests, Xray va proposer la création et la gestion de tests, la création et l’exécution de campagnes de tests ainsi qu’un reporting au travers de tableaux et graphiques récapitulatif. L’intérêt supplémentaire d’Xray est sa compatibilité avec les tickets Jira permettant d’assurer une meilleur traçabilité.
Dans quel contexte utiliser Xray ?
La vraie force d’Xray se dégage lorsqu’il est couplé à la suite Atlassian : Jira (liens US-Test) et Confluence (lien exigences). Son utilisation sera donc optimale pour les projets agiles gérés par Jira ou si d’autres projets utilisent Jira pour la gestion de leurs spécifications.
Hors projet dans Jira, il reste un logiciel de test classique et performant, mais nécessitera plus de rigueur d’utilisation de par sa liberté de choix, contrairement à un outil plus cadré tel que Micro Focus ALM (ex HP ALM). De plus les liens avec des exigences va nécéssité l’utilisation de Confluence contrairement à Micro Focus ALM ou Squash TM.
Comment ça marche ?
Les types de tickets
Comme pour Jira les différents éléments d’Xray se présentent sous forme de ticket :
Pré-condition / Pré-requis
Permet de définir des pré-requis à l’exécution de tests. Un pré-requis peut être créé une fois et associé à plusieurs cas de test.
Test Set
Permet de regrouper les cas de test en une suite de test.
Test
Défini le cas de test. Il peut être manuel avec étape / description / résultat ou alors automatique et dans ce cas-là il sera décrit soit en champ texte, soit en Gherkin.
Test Plan
Représente la campagne de test. Le Test plan va lister l’ensemble des cas de test à exécuter.
Test Exécution
Porte l’exécution des tests.
UX/UI
Permet de définir des tests sur l’interface.
Mise en place d’une campagne de test
Avant de commencer
L’une des particularité de Xray est sa liberté d’utilisation. Il faut donc trouver celle qui s’adapte le mieux au projet sur lequel il est utilisé.
Définition des Test Set
Un Test Set est une suite de test. Plus simplement c’est un objet qui va permettre de grouper un ensemble de tests. Le groupement peut se faire par fonctionnalité, par sprint…Cela va permettre d’obtenir un traitement global sur les tests (ajout à une campagne, rattachement à une US…)
Définition des Tests
Les tests manuels sont rédigés dans le ticket de test sous la forme d’étape. Chaque étape va contenir :
- Une zone action permettant de décrire l’action à réaliser
- Une zone données qui permet de saisir des données pour l’étape si nécessaire.
- Une zone résultat attendu pour décrire le résultat attendu de l’étape Il est également possible de faire appel à d’autres cas de test. Si nécessaire il est possible de rattacher une ou plusieurs préconditions au cas de test. Afin d’assurer un suivi, il est également possible de rattacher un cas de test à une US.
Définition des Test Plan
Une fois les cas de tests rédigés, il faut les rassembler dans un plan de test. Le plan de test correspond à une campagne de test. En plus de rassembler les tests, il permet également de savoir quelles sont les exécutions qui ont été lancées à partir de ce plan de test et quel est le dernier statut d’exécution de chaque test qu’il contient.
Exécution des campagnes de test
A partir du plan de test, il est possible de créer une exécution de test sur l’ensemble des tests ou sur les tests ayant un statut particulier (Failed par exemple).
Exécution
Avant de réaliser l’exécution de test il est possible de définir des paramètres tels que la version ou l’environnement de test. Une fois sur l’exécution de test, il est possible de suivre le temps passer lors de l’exécution, de modifier directement le statut d’exécution d’un cas de test ou de lancer l’exécution des tests.
Une fois l’exécution d’un test lancé, l’ensemble des éléments renseignés lors de la rédaction du cas de test sont présents. Lors du lancement d’une exécution il est possible de se chronométrer, de consulter les préconditions, de définir un statut d’exécution pour chacune des étapes, d’ajouter des preuves de tests ou de déclarer des anomalies.
Déclaration d’anomalie
Dans le cas où le résultat obtenu d’une étape ne correspond pas au résultat attendu, il est possible en plus de passer l’étape à « Failed » de créer une anomalie directement sur l’étape .
L’anomalie sera automatiquement rattachée au cas de test et à l’US. Une fois tous les tests réalisés, les informations sont reportées dans le Plan de Test et les cas de test.
Suivi / Reporting
Au cours de l’exécution ou après, il est possible de suivre l’avancement de l’exécution ou les résultats au travers de différents rapports, ainsi que la traçabilité de l’US aux exécutions de test :
Il existe également des tableaux des Plans de Test, des exécutions de test…De plus, chaque rapport est personnalisable afin de répondre au mieux aux besoins du projet.
Aller plus loin
Importer des tests
En plus de rédiger manuellement des tests, il est possible d’en importer :
- Via un fichier Excel ou CSV
- Via l’outils d’import de Xray
- Depuis HP QC/ALM
L’automatisation des tests
Si cet article présente la gestion des tests manuels, il est possible avec Xray de gérer l’automatisation des tests à travers l’utilisation de tests Génériques (simple champ texte) ou Cucumber si la méthode est plus Best Driven Developpement (langage Gherkin).
Comparatif des outils de test Ouidou
L’autre outil de test utilisé par Ouidou est Squash TM. Voici un comparatif entre les deux.
Xray | Squash TM | |
---|---|---|
Coût | Via license | Open Source |
Exigences | Nécessite un projet Confluence | Oui |
Lien US | Oui | Non |
Gestion des anomalies | Inclus avec Jira | Nécessite un interfaçage avec une appli |
Reporting | Oui | Oui |
Hierarchisation des plans de tests | Oui (mais pas très utile) | Oui |
En conclusion Xray est vraiment un plus si la gestion des US se fait dans Jira. De plus Xray permet plus de souplesse ce qui peut être piègeux si on ne fait pas attention.