Gestion des tests avec Jira

1. Création des cas de tests

La création des cas de tests dans Jira est possible avec le module Xray.

Xray permet la création et la gestion des tests via des tickets Jira. Il est difficile de projeter chaque type de ticket sur la structure de HPALM, car ils fonctionnent différemment malgré un vocabulaire similaire.

Dans Xray, on ne retrouve pas l’arborescence distincte Test Plan et Tet Lab de HPALM. Dans Xray tous les items se trouvent au même niveau et sont des tickets que l’on peut uniquement lier entre eux.

Ces tickets peuvent être caractérisés avec les objets propres à Xray suivants :

L’objet Test

Le ticket de type Test est utilisé pour la création d’un nouveau cas de test et la description de son mode opératoire.

Comme pour toute création de cas de test, les bonnes pratiques citées dans le chapitre précédent restent valables quel que soit l’outil de gestion de tests choisi.

Dans Xray, un cas de test est un ticket de type Test. Le champ Résumé qui correspond au titre du cas de test doit être parlant et compréhensible et respecte les règles de nommage définies dans le processus de test.

De la même façon que dans HPALM, il est toujours recommandé de renseigner l’objectif du cas de test.

L’objet Test offre la possibilité de décrire les étapes du cas de test, étape par étape. Cette fonctionnalité est similaire à celle prévue dans l’onglet Design Steps de HP ALM.

Les principales propriétés d’une étape de test dans Xray sont :

Comme toujours, il est préconisé de décrire aussi rigoureusement que possible les étapes d’exécution de tests, avec pour chaque étape une description et un résultat attendu et de compléter si nécessaire avec les jeux de données requis.

Vous pouvez choisir d’afficher les étapes du cas de test :

1. Propriétés d’une anomalie

La création d’une nouvelle anomalie dans Jira se fait via le menu Créer.

Le ticket anomalies dans Jira est de type Bogue.

Les principales propriétés d’un ticket anomalie dans Jira sont le résumé qui correspond au titre de l’anomalie et la description qui correspond au détail des étapes nécessaires à la reproduction de l’anomalie.

Comme toujours, les bonnes pratiques restent valables et applicables à n’importe quel outil.

Le titre doit être parlant et respecter les règles de nommage définies par l’organisation et la description de l’anomalie doit être assez détaillée pour que le développeur puisse la reproduire sans problème.

Dans la version standard de Jira, c’est-à-dire dans la version sans personnalisation, la sévérité de l’anomalie n’existe pas dans la liste des champs du ticket. On trouve uniquement le champ lié à la priorité.

Il est préconisé de demander à l’administrateur Jira au sein de votre organisation d’ajouter ce champ. La notion de sévérité est importante dans la qualification de l’anomalie. Le champ Priorité peut servir à prioriser les anomalies de même sévérité pour orienter et ordonnancer leur traitement par l’équipe de développement.

Deux autres champs à inclure dans la liste de personnalisation sont également importants.

Il s’agit d’un premier champ pour renseigner l’environnement dans lequel l’anomalie a été détectée et d’un deuxième champ pour renseigner la version dans laquelle l’anomalie a été corrigée.

Généralement, dans un outil collaboratif de gestion des tests et d’anomalies, les équipes projet et les équipes métier travaillent sur la même instance projet dans l’outil.

Dans le cadre de la gestion et du suivi du traitement des anomalies, il est important de pouvoir distinguer le portefeuille anomalies de l’équipe projet du portefeuille anomalies de l’équipe métier.

Concernant le fait de renseigner...