Qu’est-ce que Xray ?
Xray pour Jira est un outil complet de gestion des tests manuels et automatisés. Il permet de manager le cycle de vie complet des phases des tests :
- Préparation et planification des campagnes
- Conception des tests en lien avec les exigences (manuels et automatisés)
- Exécution des tests et suivi de l’avancement en temps réel
- Reportings standards et personnalisables, y compris export des données de test
Se focaliser sur l’essentiel : Les tests
La qualité de votre logiciel est garantie par votre équipe de testeurs. Et l’outil à mettre en place au sein de votre structure doit être adéquatement benchmarké, pour permettre à votre équipe d’optimiser son temps (trouver aisément son reste à faire, valider les User Stories, suivre son avancement, cloisonner le traitement des demandes en fonction des membres de l’équipe, ou non …) afin de se focaliser sur l’essentiel : les tests !
Pourquoi suis-je de prime abord réfractaire à l’outil ?
L’utilisation d’Xray requiert la manipulation d’une multitude de demande spécifique :
- Test plan
- Test Set
- Pré-condition
- Sous tâche d’exécution
- Test
- Test exécution
Il est important de maitriser l’ensemble de ces contextes pour éviter un effet « usine à gaz », lors du déploiement de l’outil en lien avec votre ou vos projets d’exigences. L’anecdote qui suit illustre ce qui se passe, lorsque le paramétrage de Xray n’est pas maitrisé.
Lors d’une de mes anciennes expériences en tant que recetteur, Jira était en place, et la société avait décidé de décommissionner HPQC ( ALM) pour basculer sur Xray pour Jira. Xray devenait donc le cœur de notre référentiel de test, et comme aucun référent n’avait été désigné ni formé, le paramétrage fût laborieux.
C’est un fait : l’outil Xray n’est pas préconfiguré comme la plupart des autres outils de tests type, ALM, Squash, etc. Par exemple, vous pouvez oubliez votre arborescence de plan de test. Elle existe sous Xray mais ne sera pas l’élément central de votre outil.
La mise en place de l’outil sans paramétrage rigoureux, sans connaissance de sa logique de fonctionnement, et sans vision commune à provoqué une perte de temps, d’argent, et de motivation, pour l’intégralité des équipes.
L’absence de conduite de changement nous à également fait perdre des automatismes à chaque évolution de paramétrage.
Pour autant, nous étions convaincus par les possibilités de reportings de l’outil. Seulement nos indicateurs étaient-ils vraiment à jour si l’équipe de recette était sous l’eau avec un outil mal paramétré et rendu complexe à manipuler ?
Alors pourquoi Xray peut-il finalement vous convenir ?
Tout d’abord le prix, le nerf de la guerre. Xray est tout de même moins cher que certains de ses concurrents (ALM). Heureusement ce n’est pas le seul argument qui plaide en sa faveur. Il ne faudrait d’ailleurs pas que ce genre de critère purement financier devienne l’élément le plus déterminant dans votre stratégie d’outillage de test.
Le premier point fort d’Xray est son excellente intégration à Jira. Vous pourrez ainsi gérer vos tests dans la suite logicielle qui suit vos User Stories et vos développements.
Le deuxième point fort d’Xray, est sa capacité d’adaptation à votre organisation et à vos processus. Les différents items Xray sont gérés comme les demandes de Jira. Il vous est donc possible de définir vos propres workflows (cycle de vie), vos propres écrans et vos propres champs personnalisés.
Tout est optimisable sur l’outil Xray, mais pour cela il faut déployer l’outil de manière « structurante ». C’est-à-dire qu’il vous faudra privilégier la simplicité d’utilisation et anticiper l’intégration à vos données existantes. Il serait contreproductif de venir polluer les User Stories avec une multitude de liens Xray par exemple.
Il est également nécessaire d’opter pour un paramétrage simpliste (le plus lean possible) et réduire au minimum les types de demandes à utiliser.
Exemples de questions à se poser :
- La sous tâche d’exécution que propose Xray apporte-t-elle vraiment de la valeur à mon processus de test ?
- Avons-nous besoin du type de demande test set + test plan ou l’un des types de demandes suffit-elle ?
- Faut-il intégrer l’environnement de test dans le projet des exigences, ou au contraire faire un projet distinct ?
- Comment optimiser au fil de l’eau (les tableaux de bord, les champs personnalisés, les types de demandes …) afin de couvrir les besoins des recetteurs et du pilotage ?
Par sa souplesse de configuration, Xray peut répondre point par point à vos besoins. Par contre, ceci requiert à mon sens une bonne réflexion préalable à sa mise en place.
Xray, un outil puissant sous réserve de bien s’en servir
Xray est un plugin très riche en options (voire trop) mais comme il est optimisable de A à Z, ce sera à vous de faire les bons choix au début de sa mise en production.
Conseil : « Pour être grand, il faut apprendre à être petit« .
Il est donc judicieux lors de la mise en place de cet outil de définir une vision commune :
- au sein de l’intégralité de votre/ vos équipes (PO, devs, intégration…) et plus consciencieusement avec votre/vos équipes de tests.
Mais aussi :
- Contacter des intervenants externes spécialisés sur ce plugin pour mettre en production l’outil au sein de votre société.
- Mettre en place une véritable conduite du changement ou à minima, des points de synchronisation avec vos équipes de recette, pour leur indiquer les changements à venir.
Xray peut devenir un véritable atout pour la gestion de vos demandes :
- Il permet à l’ensemble de votre équipe informatique de suivre l’avancement des tests,
- Il donne à votre équipe de recette une visibilité plus importante en étant au cœur de votre instance Jira (ce qui favorisera l’investissement des équipes et les échanges entre les équipes de test et de développement).
Xray est donc un bel outil à condition que son paramétrage soit bien étudié pour répondre aux besoins spécifiques de votre organisation.
