Les cas de test dans Squash TM
Qu’est ce qu’un cas de test ?
Un cas de test est "un ensemble de valeurs d‘entrée, de pré-conditions d‘exécution, de résultats attendus et de post-conditions d‘exécution, développé pour un objectif ou une condition de test particulier, tel qu‘exécuter un chemin particulier d‘un programme ou vérifier le respect d‘une exigence spécifique" (ISTQB) 1.
Chaque cas de test a pour objectif à minima de vérifier le résultat attendu spécifié par une exigence.
Dans Squash TM, un cas de test est un objet de l’Espace Cas de test. Il est définit par un objectif, un prérequis de départ, des jeux de données à constituer, des actions à réaliser et des résultats attendus. L'exécution d'un cas de test doit permettre de vérifier, étape par étape, la conformité d'un comportement attendu d'un système testé et ainsi d'identifier d'éventuelles anomalies.
Info
Pour que la couverture de test soit optimale, il est important de disposer d’une description précise du cas de test indiquant son objectif : "Le cas de test vérifie que [action]". Une exigence peut parfois être vérifiée par différents chemins possibles, il doit donc y avoir autant de cas de test que de scénarios identifiés.
Les formats de cas de test
Quatre formats de cas de test sont disponibles dans Squash TM : Classique, BDD, Gherkin et Exploratoire.
Chaque format est facilement identifiable par sa couleur dans l'espace 'Cas de test'. Dans l'arbre des cas de test, les libellés apparaissent en noir pour le format Classique, en vert pour le format BDD, en bleu pour le format Gherkin et en violet pour le format Exploratoire.
Cas de test Classique
Le cas de test classique permet de décrire via des pas de test, les actions à mener et leurs résultats attendus. Il dispose d'un bloc 'Prérequis' qui recueille les préconditions du cas de test. Il peut être variabilisé avec des jeux de données et factorisé via des appels de cas de test. Il est adapté aux tests manuels mais peut également être automatisé.
Cas de test BDD
Le cas de test BDD permet de décrire un scénario en langage Gherkin via une interface simple et intuitive proposant de l'autocomplétion 2. Chaque pas de test est composé d'un mot-clé (Given-When-Then) et d'une phrase d'action pouvant être réutilisée dans d'autres cas de test BDD. Ce format est particulièrement adapté à l'automatisation. Il permet, sans qu'il n'y ait d'impact sur la rédaction du cas de test, d'exporter le script associé au format attendu par Cucumber ou Robot Framework, Squash TM se chargeant de faire la traduction.
Cas de test Gherkin
Le cas de test Gherkin consiste en la rédaction d'un ou plusieurs scénarios Gherkin dans un éditeur de texte dédié qui propose une coloration et une vérification syntaxique, sans autocomplétion. Ce format est adapté à l'automatisation, le script Gherkin est exporté au format Cucumber tel qu'il a été rédigé par l'utilisateur.
Cas de test Exploratoire
Contrairement aux autres formats de cas de test, le cas de test exploratoire ne comporte pas de scénario ou d'étapes de test mais une charte de test qui a pour but d'apporter un cadre aux utilisateurs lors de l'exécution.
Les tests exploratoires sont complémentaires des autres formats de cas de test.
En savoir plus
Pour plus d'informations, consulter la page Gestion des tests exploratoires.
La page de consultation d’un cas de test
La page de consultation d'un cas de test s'affiche lorsqu'un cas de test est sélectionné dans la bibliothèque des cas de test.
La page de consultation d'un cas de test est constituée:
- du nom et de la référence
- de capsules indiquant le statut, l'importance et le statut de la dernière exécution
- des attributs du cas de test, de ses associations et de son contenu dans des blocs spécifiques
Info
Le nom et la référence (facultative) sont déterminés lors de la création du cas de test. Avoir un cas de test avec une référence est fortement conseillé afin d'organiser son référentiel. Il est possible de modifier la référence et le nom depuis la page de consultation du cas de test.
Il est possible d'ajouter une pièce jointe via le bouton 
en haut à droite de la page.
La barre des ancres à gauche, permet au clic sur une ancre, d'accéder au bloc correspondant :
Informations
Le bloc Informations affiche les attributs du cas de test : 'Statut', 'Importance', 'Type', 'Nature', et 'Format', sa description ainsi que ses champs personnalisés.
Exigences vérifiées par le cas de test
Le bloc Exigences vérifiées par le cas de test permet d'associer la ou les exigence(s) couverte(s) par le cas de test. Une table affiche les informations des exigences associées.
Paramètres et jeux de données
Ce bloc s'affiche uniquement pour les cas de test au format Classique et BDD.
Le bloc Paramètres et jeux de données permet de variabiliser les cas de test en valorisant leurs paramètres par des jeux de données. Les paramètres peuvent être définis au niveau des champs "Prérequis", "Action" et "Résultat attendu" pour un cas de test Classique et au niveau des actions des pas de test pour un cas de test BDD. Les jeux de données permettent de définir des ensembles de valeurs pour ces paramètres. Les paramètres renseignés dans les pas de test et prérequis sont automatiquement reportés dans la table des 'Paramètres et jeux de données'.
Cas de test appelé par
Ce bloc s'affiche uniquement pour les cas de test au format Classique.
Le bloc Cas de test appelé par liste les tests qui appellent le cas de test classique courant. Le mécanisme d'appel de test permet la construction de bibliothèques modulaires de cas de test. Lors de l'exécution, les pas de test du cas de test appelé sont vus comme des pas de test dans le cas de test appelant. Une table affiche les informations des cas de test "appelants".
Info
Ce mécanisme peut également être utilisé pour des tests de bout en bout faisant appel au patrimoine de tests de différents projets.
Prérequis et pas de test
Ce bloc s'affiche uniquement pour les cas de test au format Classique.
Le bloc Prérequis et pas de test est constitué de deux parties :
-
Prérequis : qui recueille les préconditions du cas de test
-
Pas de test : qui se compose d'une suite d'actions à accomplir pour atteindre l'objectif du test et des résultats attendus correspondants.
Pas de test
Ce bloc s'affiche uniquement pour les cas de test au format BDD.
Il permet d'ajouter des pas de test se basant sur la syntaxe Gherkin en choisissant un Mot-clé dans la liste déroulante et un rédigeant une Action.
Script
Ce bloc s'affiche uniquement pour les cas de test au format Gherkin.
Au clic, le bloc Script devient éditable et permet de rédiger des scénarios Gherkin via l'utilisation de snippets. Une aide à la rédaction des cas de test Gherkin est disponible au clic sur le bouton [Aide].
Charte de test
Ce bloc s'affiche uniquement pour les cas de test au format Exploratoire.
Le bloc Charte de test est constitué de deux éléments :
- Durée de la session de test : indique la durée (heures et minutes) d'une session de test exploratoire
- Charte : définit notamment l'objectif et le périmètre du test ou toute autre information utile permettant d'apporter un cadre aux utilisateurs lors de l'exécution
Exécutions/Sessions
Le bloc Exécutions liste les exécutions du cas de test et leurs attributs (statut, identifiant du testeur ayant exécuté le cas de test, date de l'exécution et nombre d'anomalies remontées). La table est alimentée automatiquement, en temps réel et ne peut être modifiée.
Pour les cas de test au format Exploratoire, ce bloc s'appelle Sessions et liste les sessions de test exploratoire effectuées à partir de ce cas de test.
Anomalies connues
La table Anomalies connues 3 liste les anomalies déclarées lors de l’exécution du cas de test. Elle est alimentée automatiquement et en temps réel par le bugtracker et ne peut être modifiée. Deux liens cliquables permettent à l'utilisateur d'accéder à :
- la page de consultation de l’anomalie dans le bugtracker
- la page de consultation de l’exécution durant laquelle l’anomalie a été relevée