Un avis ? Un commentaire ?
Cet espace est pour vous.
Développé depuis 2011 par Henix, une ESN française spécialisée dans la qualité logicielle, Squash TM est un outil de gestion des tests, ou test management, gratuit et open source. Très pratique, il permet à la fois de concevoir les tests, de les exécuter et de communiquer leurs résultats. Si vous souhaitez structurer ces activités et jeter à la poubelle vos antiques fichiers Excel, Squash TM est une solution intéressante à envisager !
Squash TM s’intègre dans une suite de logiciels conçus pour interagir ensemble, et qui constitue une véritable boîte à outils pour aider les testeurs dans leurs activités. Cette suite peut s’adapter à tout contexte métier ou technique, et peut accompagner la pratique de tests tant fonctionnels que non-fonctionnels. Dans cette suite, on compte également Squash TA (pour Test Automation) ou encore Squash CLI (pour Command Line Interface).
Nous utilisons Squash TM au quotidien auprès d’un grand nombre d’organisations qui l’ont intégré dans leur système d’information.
Cependant, même si cet outil est plutôt user-friendly, nous avons constaté qu’il n’était pas toujours utilisé à la hauteur de son potentiel. Voici donc aujourd’hui quelques astuces que nous avons adoptées au fil du temps et qui nous permettent d’augmenter drastiquement la performance des tests !
EDIT du 09/03/2022 : les captures d’écran visibles dans cet article ne reflètent pas la nouvelle interface de Squash TM. Toutefois, les astuces restent d’actualité ! Bonne lecture !
Ça, c’est une méta-règle, à retenir avant toute chose.
En programmation, le principe DRY (“Don’t Repeat Yourself”, en français “Ne vous répétez pas”) est un principe de développement logiciel qui consiste à éviter tout doublon dans un projet et ainsi améliorer le code, la lisibilité, la maintenance et le changement de celui-ci.
Eh bien, il est important aussi de l’appliquer aussi en gestion des tests afin de faciliter la maintenance du patrimoine de tests !
Les bonnes pratiques qui suivent vous aideront à respecter ce principe.
Pour éviter les redites, le moyen le plus efficace est d’utiliser la fonctionnalité des jeux de données de Squash TM. Trop de personnes passent à côté de cette jolie fonctionnalité qui pourtant est tellement efficace !
Imaginons une entreprise qui classe ses clients dans des segments aux noms poétiques. En fonction de son segment, chaque client a une page d’accueil personnalisée. Voici à quoi ressembleraient des tests rédigés sans utiliser la fonctionnalité des jeux de données :
On répète le nom de chaque segment 3 fois : dans le titre, dans l’action et dans le résultat attendu. Et les textes de l’action et du résultat attendu sont répété 6 fois, car il y a 6 segments. Super redondant ! Et maintenant, regroupons tout cela en un petit paquet bien rangé.
Vous voyez la syntaxe dollar/accolades ? Quand vous l’utilisez, l’onglet « Paramètres » du cas de test ajoute automatiquement le paramètre renseigné (ici, « segment »). Voyons à quoi ça ressemble, une fois qu’on a renseigné quelques valeurs possibles pour le paramètre « segment » :
Quand on ajoute dans une campagne ce cas de test comprenant 6 jeux de données, 6 « lignes » sont alors créées.
Attention à une chose toutefois : logiquement, vos 6 jeux de données auront tous la même importance (la métadonnée associée au cas de test lui-même). Si vous avez des degrés d’importance différents, il vaut mieux avoir autant de cas de test. Par exemple, si « Grenat » est un segment qui n’est plus utilisé que par une poignée de clients, qui représentent ceux qui sont en retard de paiement depuis plus de deux ans… on peut certainement considérer que l’importance du test est moindre.
Quand vous créez un jeu de données, vous devez lui ajouter un titre, qui s’affichera dans la colonne « Jeux de données » (voir copie d’écran ci-dessus). Ne négligez pas cette étape. Au fil du temps en effet, vous n’aurez sans doute plus besoin d’exécuter vos cas de test en ouvrant la popup d’exécution et en lisant attentivement chacune des étapes. Il vous suffira de lire le nom de vos cas de test et celui de vos jeux de données. C’est pour cas que vous devez bannir les titres cryptiques tels que « JDD1 » et nommer vos jeux de données le plus précisément possible.
Le nom d’un cas de test doit être descriptif et transmettre les informations nécessaires pour savoir ce qui est réellement testé. Il doit également être concis, afin d’être facile à comprendre. L’écriture d’un mauvais nom de scénario de test peut vous nuire de plusieurs façons :
Voici quelques exemples de mauvais noms de cas de test :
Pourquoi ce sont de « mauvais noms » ? Parce qu’ils parlent de fonctionnalités, mais pas de comportements attendus. Un cas de test est un scénario que l’on exécute en attendant un résultat, et le nom du cas de test doit donner une idée de ce résultat attendu… Ce faisant, cela permet de comprendre rapidement l’importance et l’enjeu de ce cas de test.
En effet, un test nommé « Page de connexion » peut recouvrir des enjeux très importants ou tout à fait mineurs. Voici, pour la liste précédente, quelques exemples de reformulation pour des cas de test d’importance très haute !
Et maintenant, voici quelques exemples de cas de test d’importance faible :
Le nom de certains cas de test vous semble un peu longuet ? C’est possible ! Mais c’est toujours plus pratique que d’avoir à ouvrir le cas de test et de fouiner dans ses étapes. Un exemple ci-dessous !
A l’inverse du nom du cas de test…
La meilleure façon d’écrire vos scénarios de test est d’avoir des étapes fort brièvement décrites, et d’aller à l’essentiel. Restez concis.
Cela vous aidera à aller droit au but, ce qui vous permettra de détecter plus facilement les anomalies.
Vous l’avez sûrement déjà lu des milliers de fois : les cas de test sont une forme de documentation. Pour autant, ils ne visent pas :
« Il faut que les cas de test puissent être exécutés par n’importe qui. » Quand vous entendez cette phrase, vous êtes donc en droit de frémir.
Vous utilisez Squash TM dans une organisation fermée ; ses collaborateurs ne sont pas « n’importe qui ». Une nouvelle recrue n’est pas non plus n’importe qui. Si elle est amenée à tester un applicatif, il est essentiel de lui expliquer la raison d’être de cet applicatif, comment il fonctionne, ce qu’il est important de tester, ce qu’on aimerait savoir à la fin d’une campagne de test. L’étape d’acclimatation fonctionnelle passe à la trappe ? Dans ce cas, ce n’est pas un profil de testeur que l’on intègre dans l’équipe, c’est un profil d’automate, et on se prive d’un précieux cerveau.
Quand on passe une heure à écrire un cas de test en entrant dans les moindres détails, c’est une heure entière que l’on passe à ne pas tester l’application. Et par la suite les testeurs nécessiteront… combien ? Cinq minutes de lecture ? Dix ? Autant de temps qui ne sera pas utilement consacré, et qui sera multiplié d’itération en itération.
Pire peut-être, si le cas de test est trop long, les testeurs fatigueront plus vite, les liront en diagonale, et passeront peut-être à côté de vérifications essentielles.
A vous donc de trouver l’équilibre parfait entre clarté et concision.
Combinée à l’utilisation des jeux de données, cette fonctionnalité vous fera faire des merveilles. Pour appeler un cas de test dans un autre, c’est-à-dire de l’ajouter comme une étape, il suffit de faire un glisser-déposer du cas de test depuis l’arborescence.
Pour reprendre l’exemple précédent : dès lors qu’un cas de test nécessitera une connexion, nous pourrons appeler le cas de test « Connexion client en fonction de son segment ». Dans l’exemple ci-dessous, nous reprenons un jeu de données renseigné précédemment, mais nous aurions pu aussi le configurer directement dans le cas de test (option « paramètres délégués »).
Un cas de test peut en appeler un autre qui en appelle un autre qui en appelle un autre… aucune contrainte à signaler à ce sujet. Il est également possible d’appeler plusieurs cas de test au sein d’un seul.
Désormais, il y a beaucoup moins de raisons de se répéter !
Avez-vous remarqué que sur la page « Informations » d’un cas de test Squash TM, il est possible de renseigner un champ dédié aux prérequis ? Malheureusement, il n’est pas possible de mutualiser ces informations entre plusieurs cas de test ayant besoin des mêmes prérequis.
Nous avons donc parfois recours à un mode de fonctionnement qui nous a permis d’économiser pas mal de temps : au lieu de remplir ce champ de pré-requis (avec le risque d’avoir à maintenir X fois ce champ en cas de changement), nous créons un dossier de cas de test « utilitaires » à appeler à volonté en première étape des cas de test en guise de prérequis.
Il arrive que les jeux de données de certains cas de test soient le résultat d’une requête SQL à lancer au préalable ; c’est donc bien plus pratique de n’avoir à modifier ce script SQL qu’à un seul endroit.
C’est là que la zone « Cas de test appelé par » s’avère très utile ! Dès qu’il faudra changer la requête, il sera possible d’effectuer une revue des impacts possibles, et de s’assurer que la nouvelle requête convient bien à tous les cas de test concernés.
Quand on crée un cas de test sur Squash TM, son champ « Importance » est par défaut alimenté avec la valeur « Faible ».
Si vous ne savez pas quels cas de test sont cruciaux, vous risquez de vous retrouver en difficulté au moment de la conception de votre campagne de test.
Avec Squash TM, il est facile de garder la trace des cas de test les plus importants et de ceux que vous pouvez déprioriser. Faites en sorte que vos cas de test reflètent ce qui est vraiment vital – et ce qui ne l’est pas.
Cela doit devenir un réflexe : ajustez l’importance du cas de test dès sa création !
Un dernier coup de pouce pour la rédaction. Si votre interface contient du texte et que ce texte n’est pas l’objet du test, il est inutile de l’indiquer directement dans les étapes du cas de test, sous peine d’occasionner des rapports d’anomalie à faible valeur ajoutée.
Le bouton de validation d’une pop-in peut être amené à changer au fil du temps : il peut en particulier changer d’intitulé (« Ok », « Valider », « Je comprends », « Oui », « D’accord », « Certes », « Pourquoi pas » ou « Tout me va »). Si cela se produit, vous n’avez pas envie d’avoir à mettre à jour une longue liste de tests. Il est donc plus pratique de désigner ce bouton comme « le bouton de validation » (donc, en utilisant une périphrase), plutôt que « le bouton ’Ok’ » ou « le bouton ‘Valider’ ».
Idem pour les messages d’erreur ! « Le message d’erreur indiquant à l’utilisateur que son mot de passe est erroné » est plus robuste que « le message ‘Mot de passe erroné’ », qui pourrait devenir « le message ‘Votre mot de passe est incorrect, merci de le saisir de nouveau’ ».
Quelle que soit votre utilisation de Squash TM, n’oubliez pas que l’objectif est de refléter vos objectifs qualité de la meilleure façon, pour obtenir des référentiels de test pertinents et efficaces. Concentrez-vous donc sur l’optimisation à chaque étape du processus et ce que vous construirez offrira à vos clients ou équipes la meilleure valeur ajoutée possible.
Ces bonnes pratiques ont pour but de vous aider à être plus efficace en travaillant avec ; n’hésitez pas à compléter avec vos propres astuces !
Cet espace est pour vous.
Salhi says:
Super