Tutoriel Xsquash

Ce tutoriel est fait pour vous permettre de découvrir Xsquash et ses nouvelles fonctionnalités.
Vous pouvez suivre les différentes étapes ci-dessous en utilisant le projet "Xsquash - Bac à sable" de notre environnement de demo (accessible ici).
Vous pouvez également consulter la vidéo de démo de Xsquash à cette adresse

 

Contexte

L’équipe d’un projet agile est constituée de différents acteurs (le product owner, le scrum master, les développeurs, les testeurs).
Le product owner a pour rôle de créer des User-story, qui correspondent à la description d’une fonctionnalité à développer. Tant que ces User-story ne sont pas traitées, elles font partie du backlog.
Le scrum master va ensuite initier un sprint et y intégrer des User-story. Le sprint est une période courte durant laquelle la team Agile va concevoir, développer et tester un ensemble de User-story dans le but d’obtenir un produit « viable ».
Toutes ces étapes vont pouvoir être réalisées dans JIRA et Squash TM par les différents acteurs.

 

Sommaire

ETAPE 1 – Dans JIRA : création d’une user story, d’une sous-tâche et d’un sprint

ETAPE 2Dans Squash TM : gestion de l’exigence synchronisée à la user-story JIRA

ETAPE 3Dans Squash TM : création et association d’un cas de test à la demande synchronisée

ETAPE 4Dans JIRA : suivi de l’avancement de la phase de conception

ETAPE 5Dans Squash TM : création automatique d’un plan de test à partir du sprint créé dans JIRA

ETAPE 6Dans JIRA : suivi de l’avancement de la phase d’exécution

 

ETAPE 1Dans JIRA : création d’une user story, d’une sous-tâche et d’un sprint

Contexte : Le product owner va créer des user-story à partir de JIRA. Celles-ci vont être créées dans le backlog. Le product owner va ensuite initier un nouveau sprint et déplacer des user-story du backlog vers le nouveau sprint.

1.1 Ouvrir JIRA : https://jira.squashtest.org
1.2 S’identifier avec les données : Login : Xsquash          Mot de passe : password
1.3 Accéder au projet « Demo-Xsquash »
  • Menu haut, cliquer sur [Projet]
  • Menu déroulant, cliquer sur [Demo-Xsquash]
1.4 Créer une demande « Récit » dans ce projet
  • Menu haut, cliquer sur [Créer]
  • Type de demande, conserver le choix sélectionné « Récit »
  • Renseigner a minima le champ « Résumé »
  • Cliquer sur [Créer]
1.5 Accéder à la fiche de la demande créée et créer une sous-tâche
  • Menu d’onglets de la demande, cliquer sur « Suite »
  • Menu déroulant, cliquer sur [Créer une sous-tâche]
  • Renseigner a minima le champ « Résumé »
  • Cliquer sur [Créer]
1.6 Retourner sur le backlog
  • Barre de navigation à gauche, premier onglet « Backlog »
1.7 Créer un nouveau sprint et glisser la demande « Récit » dans ce sprint
  • Faire défiler la page vers le bas jusqu’au backlog
  • Cliquer sur le bouton à droite [Créer un sprint]
  • Déplacer une demande du backlog vers ce sprint, par un glisser-déposer

 

Vous devez obtenir le résultat suivant :

     (A) Un sprint
     (B) Une demande de type récit
     (C) Une (ou plusieurs) sous-tâches rattachée(s) à la demande

 

 

ETAPE 2Dans Squash TM : gestion de l’exigence synchronisée à la user-story JIRA

Contexte : Dans Squash TM, les éléments créés par le product owner et le scrum master dans JIRA vont apparaître dans Squash. Un nouveau dossier apparaît dans l’arborescence, il correspond au sprint créé par le scrum master. Les user-story créées par le product owner apparaissent comme des exigences synchronisées. Elles vont pouvoir servir de base au travail de conception de l’équipe de testeurs.

2.1 Ouvrir Squash TM https://demo.squashtest.org/squash 
2.2 S’identifier avec les données : Login: Xsquash          Mot de passe : password
2.3 Accéder à l’espace Exigences
2.4 Accéder au projet « Demo-Xsquash »
2.5 Accéder au répertoire de synchronisation « Demo-Xsquash Tableau global »

 Dans le dossier de synchronisation, vous pouvez constater que les différents éléments créés dans JIRA ont été synchronisés dans Squash :

     (A) Sprint : un nouveau dossier avec le nom du sprint créé à l’étape 1
     (B) Demande « Récit » : dans ce dossier, une exigence synchronisée avec la référence et le nom renseigné dans JIRA, ainsi que l’url de la demande vers JIRA et le statut de synchronisation
     (C) Sous-tâche de la demande : synchronisée en exigence fille de la demande JIRA, avec la référence et le nom renseigné dans JIRA pour la sous-tâche

 

 

 
Répertoire de synchronisation : ce répertoire est créé lors de la première synchronisation avec le projet JIRA, et maintenu à jour automatiquement (synchronisations régulières).
Organisation du répertoire : pour une synchronisation avec un tableau scrum dans JIRA : le dossier sera organisé de la façon suivante
  • A la racine du dossier : les demandes présentes dans le backlog.
  • Dans des sous-dossiers : chaque sprint correspondant à un sous-dossier avec les demandes présentes dans chacun des sprints.
Pour les autres types de synchronisation (filtre, requête JQL) : tous les éléments sont placés à la racine du dossier de synchronisation. Voir par exemple dans le projet « Xsquash-JIRA » le dossier « FILTRE PRIORITE HAUTE ».
Réorganisation du répertoire : Les dossiers et les exigences peuvent être réorganisés au sein du répertoire cible. La seule restriction est de ne pas supprimer un sous-dossier de sprint, sinon il sera de nouveau créé.
Exigence synchronisée : elle apparaît en grisé, ce qui la distingue des exigences natives de Squash. Elle dispose de deux informations supplémentaires par rapport à une exigence native :
  • Un lien hypertexte vers le ticket JIRA d’origine.
  • Le statut de la synchronisation (permet d’alerter si la communication SquashTM/JIRA est rompue ou si une erreur est survenue lors de la dernière synchronisation).
Modification : une exigence synchronisée peut être modifiée à partir de Squash TM. Néanmoins ces modifications seront écrasées lors de la prochaine synchronisation avec les informations présentes dans JIRA. Les attributs non synchronisés (en fonction du paramétrage) peuvent par contre être modifiés librement et ne seront pas écrasés.
Suppression : une exigence synchronisée peut être supprimée à partir de Squash TM. Elle sera néanmoins recréée lors de la prochaine synchronisation. Si la demande est supprimée dans JIRA ou si la synchronisation est supprimée, l’exigence synchronisée dans Squash TM ne sera pas supprimée (politique de non-suppression). 
Hiérarchie mère-fille : le lien entre une user-story (ou tâche) et sous-tâche dans JIRA est représenté dans Squash TM par un lien exigence synchronisée mère et fille. Il est par ailleurs possible d’ajouter à une exigence synchronisée une sous hiérarchie d’exigences natives.
Déplacement : le déplacement de l’exigence synchronisée hors du projet de synchronisation entraîne la conversion de celle-ci en exigence native. Le copier-coller d’une exigence synchronisée entraîne également sa conversion en exigence native.

 

ETAPE 3Dans Squash TM : création et association d’un cas de test à la demande synchronisée

Contexte : L’équipe de testeurs va pouvoir poursuivre le travail de conception en créant des cas de test et en les liant aux user-story JIRA, pour garantir la couverture des exigences.

3.1 Accéder à l’espace Cas de test
3.2 Créer un ou plusieurs cas de test
3.3 Associer-le(s) à l’exigence synchronisée de la demande « Récit » créée à l’étape 1
3.4 Modifier le statut d’au moins un cas de test en « A approuver » ou « Approuvé »

 

 


ETAPE 4
Dans JIRA : suivi de l’avancement de la phase de conception

Contexte : Le product owner, le scrum master et les développeurs vont pouvoir suivre, sur chaque ticket JIRA, l’avancement de la phase de conception de l’équipe de testeurs avec des indicateurs et un tableau des cas de test associés à la demande JIRA.

 

Accéder à la fiche de la demande « Récit » créée à l’étape 1.

 Différentes données relatives aux cas de tests liés à cette demande apparaissent :

     (A) Un premier indicateur global (voir plus bas pour la définition de ces indicateurs)
     (B) Un champ « ratio de rédaction »
     (C) Un onglet « Cas de test Squash TM » : indique la liste des cas de test associés à cette demande, il est par ailleurs possible d’afficher leur détail

 

 

ETAPE 5Dans Squash TM : création automatique d’un plan de test à partir du sprint créé dans JIRA

Contexte : Dans Squash TM, la conception du plan de test va être facilitée et va permettre à l’équipe de testeurs d’identifier tous les cas de test à exécuter en fonction de livraison(s), sprint(s) ou en d’une requête JQL JIRA.

5.1 Accéder à l’espace Campagnes
5.2 Cliquer dans l’arborescence sur la campagne « Demo-Xsquash »
5.3 Cliquer sur l’onglet étoile puis « Concepteur de plan d’exécution JIRA… »
5.4 Suivre les différentes étapes de l’assistant :
5.5 Action : « Créer une itération dans la campagne sélectionnée »
5.6 Source des tickets JIRA : sélectionner « Dans des sprints »
5.7 Sélection des tableaux :
Tableaux : sélectionner « Tableaux JIRA liés à « Nom du projet JIRA » »
Critères sur les sprints : sélectionner « Nom du script contient » et renseigner le nom du sprint créé à l’étape 1
5.8 Sélection des sprints : laisser coché le sprint trouvé
5.9 Sélection des tickets : laisser sélectionné(s) le(s) ticket(s) trouvé(s)
5.10 Sélection des cas de test : laisser sélectionné(s) le(s) cas de test trouvé(s)
5.11 Création de l’itération : renseigner a minima le champ « Nom »
5.12 Votre plan de test a été automatiquement généré à partir des éléments sélectionnés dans l’assistant de création
5.13 Exécuter au moins un cas de test du plan d’exécution

 

 

ETAPE 6Dans JIRA : suivi de l’avancement de la phase d’exécution

Contexte : Le product owner, le scrum master et les développeurs vont pouvoir suivre, sur chaque ticket JIRA, l’avancement de la phase d’exécution de l’équipe de testeurs avec des indicateurs et un tableau des cas de test associés à la demande JIRA.

Accéder à la fiche de la demande « Récit » créée à l’étape 1

 Différentes données relatives aux cas de tests liés à cette demande apparaissent :

     (A) Un premier indicateur global (voir plus bas pour la définition de ces indicateurs)
     (B) Le champ « Ratio de vérification » 
     (C) Le champ « Ratio de validation » 
     (D) L’onglet « Exécutions Squash TM » 

 

Statut de la recette :
Il s’agit d’un champ synthétique qui présente un résumé des différents états de recette possible pour une exigence donnée.
« Non initialisé » : lorsque la conception des cas de test n’a pas commencé (aucun cas de test au statut « à approuver » ou « approuver » n’est rattaché à cette demande).
« Conception en cours » : lorsque la conception des cas de test n’est pas terminée (une partie seulement des cas de test rattachés à cette demande sont au statut « à approuver » ou « approuvé »).
« A exécuter » : lorsque la conception est terminée mais l’exécution des tests n’a pas commencé (tous les cas de tests rattachés à cette demande sont au statut « approuvé » ou « à approuver », aucun n’a encore été exécuté).
« En cours d’exécution » : lorsqu’une partie des tests seulement a été exécutée.
« Non validé » : lorsqu’au moins un des test exécutés est en échec.
« Validé » : lorsque tous les tests ont été exécutés au moins une fois et qu’ils sont tous au statut « succès » ou « arbitré ».  
 
Taux de Rédaction :
Ce taux permet de suivre l’avancement de la rédaction des cas de test. Pour une exigence synchronisée donnée ce taux est égal à :
Nombre de cas de test couvrant l’exigence ou l’une de ses descendantes et au statut « à approuver » ou « approuvé »
/ Nombre de cas de test couvrant l’exigence ou l’une de ses descendantes quel que soit le statut
Si une exigence n’est pas couverte, le taux vaut 0.
Ratio de Rédaction :
Ce champ reprend la valeur du taux de rédaction suivi du nombre de cas de tests concernés (X/Y cas de test).
 
Taux de Vérification :
Ce taux permet de suivre l’avancement de l’exécution des cas de test liés à une exigence ou à l’une de ses filles.
Pour une exigence synchronisée donnée ce taux est égal à :
Nombre d’ITPI lié à un cas de test couvrant l’exigence synchronisée ou l’une de ses descendantes ayant un statut d’exécution final (Bloqué, Echec, Non testable, Succès, Arbitré), en ne tenant compte que de la dernière exécution (ou du dernier fast pass)
/ Nombre d’ITPI lié à des cas de test couvrant l’exigence synchronisée ou l’une de ses descendantes
Un ITPI étant un item de plan de test, aussi appelé instance de cas de test. Il s’agit des objets présents dans les plans d’exécution des itérations dans l’espace Campagnes de Squash TM.
Ratio de Vérification :
Ce champ reprend la valeur du taux de vérification suivi du nombre de cas de tests concernées (X/Y cas de test).
 
Taux de Validation :
Ce taux permet de suivre la validation d’une exigence. Pour une exigence synchronisée donnée ce taux est égal à :
Nombre d’ITPI lié à un cas de test couvrant l’exigence synchronisée ou l’une de ses descendantes ayant un statut d’exécution validé (Succès ou Arbitré), en ne tenant compte que de la dernière exécution (ou du dernier fast pass)
/Nombre d’ITPI lié à un cas de test couvrant l’exigence synchronisée ou l’une de ses descendantes ayant un statut d’exécution final, en ne tenant compte que de la dernière exécution (ou du dernier fast pass)
Un ITPI étant un item de plan de test, aussi appelé instance de cas de test. Il s’agit des objets présents dans les plans d’exécution des itérations dans l’espace Campagnes de Squash TM.
Ratio de Validation :
Ce champ reprend la valeur du taux de validation suivi du nombre de cas de tests concernées (X/Y cas de test).