Configurer Squash TM pour l'automatisation

Authentification par token

L'exécution des tests automatisés depuis Squash TM utilise des jetons d'API temporaires. Par conséquent, la propriété squash.rest-api.jwt.secret est requise pour pouvoir exécuter des tests automatisés avec Squash Orchestrator depuis Squash TM.

Définir l'URL publique de Squash TM

L'URL publique de Squash TM doit impérativement être renseignée dans les Paramètres Système de l'espace Administration pour que les résultats d'exécution des tests automatisés exécutés dans Squash Orchestrator remontent dans Squash TM.

Créer un utilisateur pour le serveur d'exécution automatisée

Pour utiliser Squash en DevOps, il est impératif de créer un utilisateur appartenant au groupe "Serveur d'automatisation de tests" dans Squash TM pour pouvoir récupérer un plan d'exécution Squash TM via un workflow envoyé depuis un pipeline. Plus de détails sur le fonctionnement de Squash en DevOps sont disponibles dans le guide de récupération d'un plan d'exécution Squash TM depuis un workflow.

La création de l'utilisateur technique n'est pas obligatoire lorsque les tests automatisés sont exécutés depuis l'interface de Squash TM (depuis les espaces Itération et Suite).

Paramétrer le projet

La configuration d'un projet est accessible depuis l'espace Administration, en cliquant sur le sous-menu Projets. Cliquer sur le projet désiré pour afficher la page de consultation du projet.

Info

Seul un administrateur ou un chef de projet peut configurer un projet.

L'ancre Automatisation du panneau d'administration permet de configurer l'automatisation du projet.

Il est possible depuis ce bloc de :

• paramétrer la technologie d'implémentation et la langue des scripts BDD ;
• activer un workflow d'automatisation (Squash ou Jira) ;
• gérer le nettoyage des suites automatisées :
  • paramétrer une durée de conservation des suites automatisées ;
  • supprimer les suites automatisées ;
  • supprimer les pièces jointes des exécutions ;
• associer un serveur de partage de code source ainsi qu'un dépôt (si un workflow d'automatisation est activé) ;
• associer un serveur d'exécution automatisée et définir des environnements par défaut pour les serveurs Squash Orchestrator.

Technologie d'implémentation et langue des scripts

Il est possible pour chaque projet de configurer la technologie d'implémentation des cas de test BDD ainsi que la langue des scripts BDD. Le chef de projet a le choix entre Cucumber et Robot Framework pour la technologie d'implémentation.

Si la technologie Cucumber est sélectionnée, il est possible de choisir parmi les quatre langues suivantes pour le script : anglais, français, espagnol et allemand.
Pour la technologie Robot Framework, l'anglais est la seule langue disponible.

Workflow d'automatisation

L'activation du workflow d'automatisation pour un projet se fait via une liste déroulante.

Par défaut, l'option "Aucun" est sélectionnée.
L'option "Squash avancé" déclenche l'activation du workflow Squash avancé, tandis que "Squash simple" déclenche l'activation du workflow Squash simple.
Lorsque le plugin Workflow Automatisation Jira est activé sur le projet, le workflow d'automatisation est valorisé à "Serveur distant".

L'activation d'un workflow d'automatisation entraîne l'apparition de nouveaux champs dans le bloc Automatisation d'un cas de test.
Dans le cas du workflow Squash avancé, les tests à automatiser sont suivis dans l'espace Automatisation à la fois par les testeurs et par les automaticiens.
Si c'est le workflow Squash simple ou le workflow Jira qui est activé, le suivi des tests à automatiser se fait directement depuis le bloc Automatisation des cas de test.

L'activation d'un workflow d'automatisation entraîne également l'apparition d'une partie Serveur de gestion de code source dans le bloc Automatisation d'un projet.

Nettoyage des suites automatisées

Durée de conservation

La durée de conservation des suites de tests automatisées du projet se fixe en jours. Lors d'un nettoyage (des suites automatisées, ou bien des pièces jointes), tous les éléments inclus dans le périmètre de cette durée de conservation sont conservés tandis que les autres sont supprimés.

Si aucune durée n'est définie, la durée de vie des suites est considérée comme infinie. Par défaut, aucune valeur n'est renseignée.

Suppression des suites automatisées

Il est possible de supprimer toutes les suites automatisées dont la date de création est antérieure à la durée de conservation définie précédemment.

Le clic sur le bouton [Supprimer] ouvre une pop-up avec un avertissement, indiquant notamment que la suppression est définitive ainsi qu'un décompte du nombre de suites automatisées et exécutions concernées par la suppression.

La suppression entraîne la suppression des suites automatisées ainsi que tout ce qu'elles contiennent : exécutions et pièces jointes.

Suppression des pièces jointes

Il est possible de supprimer toutes les pièces jointes associées aux exécutions des suites automatisées dont la date de création est antérieure à la durée de conservation définie précédemment.

Le clic sur le bouton [Nettoyer complètement] ouvre une pop-up avec un avertissement, indiquant notamment que la suppression est définitive, et qu'elle concerne toutes les pièces jointes associées aux exécutions (y compris les rapports d'exécution pour les cas de tests dont le statut n'est pas succès).

Il est possible de supprimer les pièces jointes associées aux exécutions ayant un statut succès des suites automatisées dont la date de création est antérieure à la durée de conservation définie précédemment.

Le clic sur le bouton [Nettoyer partiellement] ouvre une pop-up avec un avertissement, indiquant notamment que la suppression est définitive et qu'elle ne concerne que les pièces jointes associées aux exécutions dont le statut est succès.

Associer un serveur de partage de code source

Lorsque le workflow d'automatisation est activé, une partie Serveur de gestion de code source apparaît dans le bloc Automatisation. Il faut au préalable avoir créé un serveur de partage de code source dans l'espace Administration>Serveurs pour pouvoir le sélectionner et l'associer à un projet. Une fois le serveur sélectionné, les noms de ses dépôts ainsi que leur branche s'affichent dans une liste déroulante.

Il est possible de reprendre l'arborescence de Squash TM dans le dépôt lors de la transmission des cas de test à l'outil de partage de code source afin qu'ils soient organisés de la même manière des deux côtés. L'activation de cette fonctionnalité se fait au niveau du champ Utiliser l'arborescence de TM dans le dépôt.

En savoir plus

Pour en savoir plus sur la création d'un serveur de partage de code source, consulter la page Gérer les serveurs de partage de code source.

Info

Pour un projet configuré avec un serveur Squash Orchestrator, si un dépôt de serveur de partage de code source est configuré sur le projet, les champs Technologie du test automatisé, URL du dépôt de code source, Référence du test automatisé sont complétés automatiquement lors de la transmission des cas de test.

Associer un serveur d'exécution automatisée

Il suffit de sélectionner le serveur voulu au niveau de la liste déroulante proposée pour le champ Serveur d'exécution automatisée et de confirmer le choix afin que les tests automatisés du projet puisse s'exécuter par son intermédiaire.

Il faut au préalable avoir créé un serveur d'exécution automatisée dans l'espace Administration>Serveurs pour pouvoir le sélectionner et l'associer à un projet.

En savoir plus

Pour en savoir plus sur la création d'un serveur d'exécution automatisée, consulter la page Gérer les serveurs d'exécution automatisée.

Pour les serveurs Squash Orchestrator (type "Squash Orchestrator"), une fois le serveur sélectionné, une section Environnement par défaut s'affiche.

Elle permet de :

• indiquer quels sont les environnements visibles par le projet ;
• consulter et définir les tags d'environnement par défaut du projet ;
• associer les variables d'environnement au projet et définir leur valeur par défaut ;
• récupérer les informations sur les workflows exécutés dans le projet.

Définir les environnements visibles par le projet

Au niveau de Squash Orchestrator, lors de la génération de jeton, il est possible d'indiquer les ressources auxquelles il a accès. Selon les permissions accordées, chaque jeton peut ainsi avoir accès à un ensemble d'environnements.

En savoir plus

Pour plus d'informations sur la notion de permissions associées à un jeton, consulter la page Namespaces sur la documentation OpenTestFactory.

Dans Squash TM, le champ Jeton permet de définir un jeton au niveau du projet en remplacement de celui défini au niveau du serveur d'exécution. Cette fonctionnalité permet ainsi de contrôler et de compartimenter l'accès aux environnements d'exécution pour chaque projet.

Si ce champ est laissé vide, les environnements accessibles par le jeton défini au niveau du serveur d'exécution automatisée sont visibles au niveau du projet.

Ce champ est obligatoire si aucun jeton n'a été défini au niveau du serveur d'exécution automatisée.

Consulter et définir les tags par défaut du projet

Le champ Tags d'environnements par défaut permet de consulter et définir les valeurs par défaut pour le projet.
Si des valeurs par défaut ont déjà été définies au niveau du serveur d'exécution automatisée et qu'aucun jeton n'est défini pour le projet, elles s'affichent automatiquement.
Il est toutefois possible de définir de nouvelles valeurs par défaut pour le projet. Dans ce cas, ce sont ces valeurs qui sont proposées par défaut à l'utilisateur à l'exécution des tests.

Si un jeton est défini pour le projet, les valeurs par défaut du serveur sont supprimées et il est nécessaire de définir de nouvelles valeurs par défaut parmi les tags associés aux environnements accessibles via le jeton.

Associer des variables d'environnement au projet et définir leur valeur par défaut

Dans la section Variables d'environnement figurent les variables d'environnement associées au projet.

Depuis cette section, il est possible d'associer des variables d'environnement au projet et de définir leur valeur par défaut.
Pour associer une variable d'environnement au projet, cliquer sur le bouton et sélectionner la ou les variables d'environnement à associer.
Une fois la variable d'environnement associée, il est possible de lui attribuer une valeur par défaut. Selon le type de variable d'environnement, différents caractères sont autorisés. Cette valeur est proposée par défaut à l'utilisateur lors de l'exécution des tests mais il peut la modifier.

Par défaut, les variables d'environnement associées au serveur d'exécution automatisée sont automatiquement associées au projet avec leur valeur par défaut, si elle a été définie.
Comme pour les tags d'environnement, il est possible de définir une nouvelle valeur par défaut pour le projet.

Pour dissocier une ou plusieurs variables d'environnement d'un projet, cliquer sur le bouton . Si la variable d'environnement est également associée au serveur d'exécution automatisée, elle est dissociée uniquement du projet.