Gérer vos tests avec Squash TM

23 Mai 2019
squash TM tests
L’outil Squash est composé de différents modules permettant la structuration et l’industrialisation des tests fonctionnels d’un logiciel ou d’une application informatique. Faisons ensemble un tour de cet outil !

Squash TM (Test Management) est un outil de gestion de patrimoine test (généralement fonctionnel), full web, qui a l’avantage d’être une solution libre. Il est compatible avec les navigateurs Firefox, Chrome, Internet Explorer ou Safari.

Il permet de travailler en multi et inter-projets, ce qui le distingue de ses concurrents.

Squash TM est découpé en 3 espaces : les Exigences, les Cas de test et les Campagnes, rattachés entre eux de la façon suivante :

  • Une exigence peut être liée à un ou plusieurs cas de test,
  • Un cas de test peut répondre à une ou plusieurs exigences,
  • Un cas de test peut être associé à une ou plusieurs campagnes de test,
  • Une campagne de test peut contenir un ou plusieurs cas de test

L’ordre suivant est conseillé par AUSY pour la définition des espaces : exigence, cas de test, campagne.

1. L’espace des exigences

C’est un espace où l’on va définir l’expression d’un besoin, c’est-à-dire la description de ce qu’un produit doit réaliser. En d’autres mots, cela correspond aux règles métier à appliquer.

On donne un titre et une description à chaque exigence créée, ainsi qu’une criticité (mineure, majeure ou critique) et une catégorie (fonctionnelle, ergonomique, technique, …) afin d’optimiser les rapports de suivi.

Les exigences sont rangées dans une arborescence libre, créée par l’utilisateur. AUSY met en place et recommande la bonne pratique suivante : utiliser les fonctionnalités de l’application à tester pour réaliser le découpage de l’arborescence.

squash TM image 1

Fig1 - Exemple de l’espace des Exigences et son arborescence

2. L’espace des cas de test

C’est un espace de définition, où l’on répertorie l’ensemble des tests à réaliser par projet. On associe à chaque test une ou plusieurs exigences.

Les tests peuvent être rangés dans une arborescence identique à celle créée pour les exigences.

squash TM image 2

Fig2 - Exemple arborescence de l’espace Cas de tes et un cas de test

La définition d’un test est construite grâce à l’ajout d’un ou plusieurs pas de test, c’est-à-dire d’étape(s) du test, avec un résultat attendu pour chacun(e) dans le logiciel à tester.

squash TM image 3

Fig3 - Exemple de la définition des pas de test

Chaque pas de test peut contenir des variables afin de mutualiser le cas de test en question avec plusieurs éléments à tester.

Par exemple, si l’on veut tester l’accès à une page d’authentification d’une application, nous pouvons passer en variable le login et le mot de passe au niveau de la définition des pas de test :

squash TM image 4

Puis ajouter les jeux de données que l’on souhaite tester dans la partie Paramètres :

squash TM image 5
Ainsi, à l’exécution, nous jouerons ce cas de test autant de fois qu’il y a de jeux de données définis.

3. L’espace de campagnes

C’est un espace qui permet l’exécution des cas de tests. On retrouve la notion d’arborescence dans cet espace, puisque l’on y créé au préalable un dossier par version dans lequel on ajoute une campagne de tests. Dans celle-ci, nous pourrons alors ajouter des cas de test, chacun associé à des itérations.

L’exécution des cas de tests est lancée manuellement dans Squash TM et sa réalisation se déroule en parallèle des actions réalisées sur le logiciel à tester. On développe les pas de test un à un, en indiquant le statut de ces derniers (succès, échec, bloqué, non testable). On y renseigne le planning prévisionnel, puis le réel lors de l’exécution.

squash TM image 6

Fig5 – Exemple exécution cas de test

En cas d’anomalie constatée lors de l’exécution d’un pas de test, l’outil Squash TM permet de saisir cette anomalie directement à partir du pas de test en question, et ce sous plusieurs bugtracker. Pour cela, il faut bien entendu que le client utilise ce type d’outil.

squash TM image 7
                           Fig6 -  Exécution pas de test                                                                          Fig7 - Rapport d’anomalie vers JIRA par exemple

 

Une fois l’anomalie créée à partir de Squash TM, cette dernière est consultable directement dans le bugtracker. La description de l’anomalie contient les pas de test qui ont été exécutés et celui qui est en erreur, avec son explication décrite par le testeur. On peut y attacher des pièces jointes en complément. Le cycle de vie de l’anomalie prend ensuite la relève au sein du bugtracker.

4. Pilotage

En plus des trois modules préalablement décrits, un espace de pilotage est également présent dans l’application. Il permet d’extraire, sous forme de tableau, la synthèse d’avancement des tests par projet, par campagne, ou encore couverture des exigences.

Ces tableaux sont rapides à réaliser, simples d’analyse et un bon moyen de communication afin de présenter l’avancement des équipes de test. L’extraction peut se réaliser sous divers formats (XLS, PDF, HTML) et est ainsi transférable aux autres équipes ou à l’organisation.

squash TM image 8

 

L’agilité avec Squash : exemple avec le bugtracker JIRA

Les équipes de testeurs d’AUSY évoluent dans des écosystèmes applicatifs au degré d’agilité de plus en plus élevé. Or, l’outil Squash est compatible avec les principes agiles. Pour répondre à ce type de besoins, on utilise le plugin paramétrable XSquash, qui permet une intégration de Squash TM dans le Workflow JIRA.

Liens entre JIRA et SQUASH

Ce plugin permet de synchroniser les informations présentes dans JIRA et Squash TM, de remonter les informations sur les tests, puis faire le lien avec les User Stories créées par le Product Owner dans JIRA. Cela permet donc de centraliser l’information en la rendant disponible et fiable, d’éviter les doubles saisies et donc d’accélérer les prises de décisions.

Cela s’adapte également au niveau de l’organisation. On peut en effet créer un dossier Squash par sprint défini dans JIRA. Il est également possible de gérer les exigences synchronisées dans Squash TM suite à la création des User Stories dans JIRA. On va ensuite pouvoir créer les cas de test directement dans Squash TM. Et, côté pilotage, le suivi de l’avancement, de la conception et de l’exécution des cas de tests se fait dans JIRA. On pourra présenter, par ticket, le(s) cas de test associé(s), les jeux de données utilisés ou encore le taux de rédaction.

Il faut cependant bien noter et prendre en compte que JIRA reste maître des exigences et Squash TM des anomalies.

 

Squash TM est un outil innovant, simple d’accès, dont on comprend rapidement les fonctionnalités. Il est full web, ce qui facilite son utilisation. C’est également un très bon outil de partage d’informations, de gestion de jeux de données et de diffusion de rapport de pilotage. Squash TM est robuste, avec une très bonne ergonomie. De plus, il évolue sans cesse pour tenir compte des axes d’amélioration à partir des retours utilisateurs.

Pour l’ensemble de ces raisons, AUSY utilise Squash TM chez plusieurs de ses clients actuels pour leur gestion des tests.

 

squash TM image 10
L’auteur :

Anthony CHAUVEAU a rejoint AUSY en 2010 après une formation MIAGE. Au cours de sa carrière, il a œuvré dans le secteur des Mutuelles, du Télécom, et de la Retraite. Bien qu’ayant commencé à travailler aux études, il est actuellement en charge de la coordination de recette/qualification.

 

Aussi n’hésitez pas à visiter notre page web dédiée aux Tests Logiciels.

Parlons ensemble de vos projets. 

contactez-nous