Cette nouvelle livraison contient un Squash Orchestrator constitué d'une seule image Docker. Au lieu d'être dans une image jusqu'ici séparée, les micro-services exclusifs Squash Ultimate sont désormais intégrés dans l'image principale de Squash Orchestrator. Ils ne seront lancés que si un fichier de licence est lié au conteneur et que ce fichier contient une licence Ultimate. Comme déjà mentionné dans une news précédente, cette image est maintenant signée. Ces améliorations visent à simplifier le déploiement et à renforcer sa sécurité. Sur le plan fonctionnel, plusieurs fonctionnalités ont aussi été ajoutées : Les tests JUnit @Nested sont désormais supportés. Cette fonctionnalité de JUnit permet de regrouper les cas de test au sein d'une hiérarchie, permettant le partage du code d'installation et la mise en place d'une organisation reflétant la relation entre les tests. L'Orchestrator peut être pingé ou sollicité en mode "dry-run". Cela peut servir à tester de nouveaux déploiements et à surveiller l'Orchestrator, ou à vérifier si un workflow est correct ou non. Les logs de l'Orchestrator sont maintenant configurables (profondeur des pas, profondeur des jobs, longueur maximale). Parallèlement, nous avons poursuivi nos efforts pour continuer à réduire la consommation de mémoire en ajoutant des agrégateurs de services. Etant donné le retard de livraison, il n'y aura pas de 2024-02. La livraison 2024-03 sera toujours centrée sur Squash Orchestrator, apportant un nouveau rapport HTML donnant un aperçu de l'ensemble de l'itération ou de la suite de tests (ce rapport vise à remplacer Allure à moyen terme) et continuant à optimiser l'utilisation de la mémoire.

Les images Docker de Squash et OpenTestFactory sont désormais signées. La signature des images Docker renforce la sécurité de vos applications conteneurisées en garantissant que seules des images vérifiées et non altérées sont utilisées dans vos environnements. Le passage d'images non signées à des images signées ne devrait pas avoir d'impact sur vos habitudes (vous pouvez les utiliser avec les mêmes commandes Docker). Mais, en raison de certains problèmes techniques, nous ne sommes pas en mesure de signer l'image squashtest/squash-tm. Nous avons donc décidé de fournir l'image signée Squash TM sous le nom squashtest/squash. Pendant toute l'année 2024, nous fournirons à la fois l'image non signée squashtest/squash-tm et l'image signée squashtest/squash. Mais en 2025, nous cesserons de créer des images squashtest/squash-tm. Cela signifie que, durant 2024, vous devrez mettre à jour vos scripts d'installation afin qu'ils utilisent squashtest/squash au lieu de squashtest/squash-tm. Par ailleurs, l'image des micro-services Squash Ultimate (permettant à ceux qui ont une ancienne licence Squash AUTOM Premium, ou une nouvelle licence Squash Ultimate, d'accéder aux fonctionnalités commerciales d'automatisation des tests) disparaîtra avec l'Orchestrator 4.9.0 (en 2024-01). Tous les micro-services, Community ou Ultimate, seront dans l'image de Squash Orchestrator, les micro-services Ultimate étant conditionnés par la présence d'une licence Ultimate. Pour rappel, voici la liste de toutes les images que nous fournissons : La signature peut être vérifiée à l'aide de la commande "docker trust inspect" : Pour plus d'informations, voir https://docs.docker.com/engine/security/trust/.

La version 6.0 de Squash est disponible. Cette version comporte les évolutions suivantes : Préparation, exécution et revue de sessions de tests exploratoires Authentification via OpenID Connect Configuration des colonnes affichées dans les tables Amélioration des tableaux de bord de l’Espace Campagnes Supervision des synchronisations Personnalisation des templates des rapports éditables Remontée en temps réel des résultats des tests automatisés Utilisation des données de Squash TM dans une quality gate Configuration additionnelle des serveurs Squash Orchestrator Amélioration de l’expérience utilisateur Évolutions sur les API Optimisation des performances Évolutions Squash Orchestrator Découvrez-les principales nouveautés de Squash 6.0 ci-dessous. Pour la liste complète des évolutions et corrections, vous pouvez consulter la release note de la version. 6.0 et de Squash Orchestrator. Préparation, exécution et revue de sessions de tests exploratoires Squash 6.0 apporte la gestion des tests exploratoires et plus précisément la préparation, l’exécution et la revue de sessions. Préparation de la session Créez vos chartes de tests exploratoires grâce à un nouveau format de cas de test. Définissez l’objectif, le périmètre, la durée et toute information utile pour réaliser vos sessions. Créez et planifiez vos sessions de tests exploratoires à partir des chartes. Ajoutez des participants aux sessions et répartissez les tests entre eux. Exécution de la session Exécutez les sessions de tests exploratoires en ajoutant au fil de l’eau des notes indiquant brièvement les observations ou tests effectués et remontez directement les anomalies depuis l’exécution. Gérez votre temps grâce à un timer. Supervisez la session grâce aux indicateurs et à une vue d’ensemble de l’activité des participants. Revue de la session Effectuez la revue et le bilan de la session. Authentification à Squash via OpenID Connect Nécessite le plugin OpenID Connect, inclus avec l’offre Squash Premium. L’authentification à Squash via OpenID Connect est désormais possible. Connectez-vous à Squash via votre compte Google, GitLab, Okta, Microsoft ou tout autre fournisseur d’authentification compatible avec OpenID Connect. Configuration des colonnes affichées dans les tables Nécessite le plugin Squash TM Premium, inclus avec l’offre Squash Premium. Les colonnes affichées dans les tables de résultats de recherche, dans les plans d’exécution et dans les suites automatisées sont maintenant configurables par utilisateur. Dans les résultats de recherche, configurez des colonnes supplémentaires, notamment les champs personnalisés, pour un affichage au plus proche de vos besoins et exportez vos résultats pour un reporting sur mesure. Améliorations des tableaux de bord de l’espace Campagnes Les tableaux de bord de l’espace Campagnes peuvent à présent être affichés pour un projet ou une sélection multiple d’éléments. Une option permet de prendre en compte uniquement le dernier résultat d’exécution ou tous les résultats de chaque test dans ces graphiques. Supervision des synchronisations Un nouvel espace dans l’administration permet à l’administrateur et au chef de projet de monitorer l’ensemble des synchronisations paramétrées sur l’instance et de faciliter l’identification des erreurs. Depuis cette vue, identifiez les synchronisations en échec ou désactivées, visualisez le projet, le serveur et le périmètre lié à chaque synchronisation et accédez au journal d’erreurs spécifique à chaque synchronisation en échec. Personnalisation des templates des rapports éditables Nécessite le plugin Squash TM Premium et l’offre Squash Ultimate. Il est désormais possible d’utiliser des templates personnalisés pour générer les rapports éditables (cahier d’exigences, cahier de test, bilan de campagne et d’itération). Ajoutez et gérez vos templates personnalisés pour chaque rapport dans un espace dédié de l’administration. À la création du rapport dans l’espace pilotage, sélectionnez le template le plus adapté à votre organisation et à vos besoins. Remontée en temps réel des résultats des tests automatisés Les résultats et les rapports des tests automatisés lancés depuis Squash TM avec Squash Orchestrator sont désormais remontés en temps réel dans l’outil. Suivez la progression de l’exécution de vos tests dans la fenêtre de supervision des tests automatisés et visualisez le statut d’exécution et les rapports des tests au fur et à mesure de leur exécution. Utilisation des données de Squash TM dans une quality gate Les caractéristiques des cas de test (importance, nature, type, CUF…) peuvent désormais être utilisées dans la définition des quality gates intégrées dans vos pipelines CI/CD. Configuration additionnelle des serveurs Squash Orchestrator Nécessite le plugin Squash TM Premium et l’offre Squash Ultimate. La configuration des serveurs Squash Orchestrator est enrichie et permet à présent d'envoyer directement depuis Squash TM des données à Squash Orchestrator lors de la création d'un workflow (hooks, variables d'environnement, ressources…). Amélioration de l’expérience utilisateur Squash 6.0 comporte un certain nombre d’évolutions visant à améliorer l’ergonomie et l’expérience utilisateur : coller des images dans les champs riches avec ajout en pièces jointes, prévisualisation des pièces jointes, persistance de la taille des colonnes redimensionnées… Des fonctionnalités visant à faciliter la configuration des serveurs automatisés ainsi que l’exécution et l’analyse des tests automatisés ont également été ajoutées : visualisation des résultats des 5 dernières exécutions depuis un plan d’exécution, filtres sur les suites automatisées, accès aux rapports des tests automatisés dans la fenêtre de détail des tests… Évolutions des API Il est désormais possible via les API de Squash de récupérer l’identifiant et l’URL des anomalies associées à un objet (exécution, campagne, exigence…). Les variables d’environnement sont également gérées via les API. Optimisation des performances Cette nouvelle version améliore les performances de Squash, notamment lors de l’affichage des résultats de recherche ou de certains objets (projet, rapports…) et de la suppression d’exigences ou de celle d’un projet. Évolutions Squash Orchestrator Une nouvelle version de Squash Orchestrator (4.8.0) permet l’ajout d’options sur la ligne de commande utilisée pour lancer les tests depuis Squash TM (via l’utilisation de variables d’environnement). Deux nouvelles commandes (« opentf-ctl get attachments » et « opentf-ctl cp ») permettent désormais de lister et récupérer les attachments (rapports, captures d’écran…) créés lors de l’exécution des tests. À fin de simplification, l’évaluation d’une qualigy gate peut désormais être demandée directement au lancement d’un workflow (« opentf-ctl run workflow »), il n’est plus nécessaire d’effectuer une seconde étape (« opentf-ctl get qualitygate »).

Nos efforts pour réduire la consommation de mémoire, tant pour l'image de l’Orchestrateur Squash que pour celle des services Premium, atteignent enfin une étape importante : tous nos microservices Java sont maintenant portés sur Micronaut (https://micronaut.io/), ce qui permet un démarrage plus rapide et, plus important encore, une réduction de la consommation de mémoire : l’Orchestrateur Squash nécessitant désormais 1,5 Go (contre 5 Go il y a un an) et les Premium Services 0,5 Go (contre 2 Go). Cette migration technologique a été beaucoup plus douloureuse que prévu. La livraison tardive de 2023-10 est un autre symptôme des difficultés que nous avons rencontrées. Cette migration devrait être totalement transparente pour les utilisateurs de Squash AUTOM/DEVOPS. Cette livraison ajoute la publication des résultats d’une quality gate sous forme de note et, optionnellement, sous la forme d’un label dans une merge request ou une issue GitLab. La documentation de Squash DEVOPS donne quelques exemples de configuration pour la publication des résultats d’une quality gate dans le pipeline CI/CD de GitLab. Pour donner une vue d'ensemble de la fonctionnalité, voici un résumé de l'ensemble du workflow : Un ingénieur DevOps configure l'exécution d'un plan de test (défini dans Squash) et de la quality gate pour les merge requests dans le pipeline CI/CD (fichier .gitlab-ci.yml). L'équipe de test a maintenant la pleine propriété des tests qui devraient être exécutés sur chaque merge request. Dans Squash, elle peut ajouter ou supprimer des tests au fur et à mesure de l'avancement du projet, de l'implémentation de nouvelles fonctionnalités, de l'évolution des critères de qualité... Chaque fois qu'un développeur propose une merge request pour modifier la base du code, celle-ci est validée par rapport à ces tests. Une fois que les tests ont été exécutés et que la quality gate a été évaluée, un commentaire est ajouté à la merge request (ceci est très similaire pour d'autres quality gates telles que celle de SonarCloud). Des labels indiquant le résultat de la quality gate peuvent également être ajoutés, ce qui facilite l'identification rapide des merge requests qui ont échoué. Un nouveau endpoint a été ajouté à l'Orchestrateur pour récupérer les rapports de test. Les outils de l’Orchestrateur ont été complétés pour exploiter cet endpoint : "opentf-cp" peut être utilisé pour récupérer un rapport. Cette fonctionnalité sera encore améliorée dans la prochaine version afin de simplifier l'enregistrement des rapports en tant qu'artefacts d'un pipeline CI/CD GitLab. En raison du retard de livraison, 2023-11 sera annulée. La livraison 2023-12 devrait apporter les fonctionnalités suivantes : l'ajout simple de rapports de tests aux pipelines GitLab, la possibilité d'ajouter des paramètres Squash à la ligne de commande utilisée pour lancer les tests, et la mise à jour de Micronaut de 3 à 4. Chaque livraison d'AUTOM/DEVOPS contient plusieurs composants ayant chacun son propre numéro de version. Vous pouvez les consulter dans nos release notes version par version.

2023-09 est une livraison de maintenance contenant plusieurs améliorations et quelques corrections de bugs. Les améliorations les plus notables sont les suivantes : L'Orchestrateur est maintenant capable d'exécuter des tests JUnit via Maven Daemon (c'était auparavant déjà possible pour les tests Cucumber). Maven Daemon (mvnd) est un remplacement direct de Maven (mvn). Comme il s'agit d'un daemon, il n'est démarré qu'une seule fois et, comme il s'agit d'une application native (elle est construite avec GraalVM), il démarre plus rapidement. Cela signifie que nous n'avons pas à payer le coût du démarrage de la JVM à chaque fois que nous lançons un test. Pour les tests JUnit et Cucumber courts, qui durent quelques secondes, l'overhead du démarrage de la JVM est un problème. Si vous avez de tels tests, nous vous conseillons de remplacer Maven par Maven Daemon, une FAQ AUTOM/DEVOPS détaille comment faire. Pour les tests plus longs, tels que les tests d'interface utilisateur, le gain de la migration vers Maven Daemon sera négligeable. Les résultats d'opentf-ctl sont plus faciles à parser par des scripts : ils sont maintenant affichés dans des colonnes à largeur fixe et les formats YAML ou JSON peuvent être utilisés. Les sélecteurs de labels et des fields sont désormais utilisables pour toutes sous-commandes opentf-ctl pour laquelle une sélection est applicable. Certaines de ces sous-commandes supportent également le drapeau "--all". Et nous avons les améliorations régulières sur les messages et les logs... Pour rappel, les nouvelles versions de Squash AUTOM et DEVOPS sont livrées mensuellement (sauf en août). 2023-10 devrait permettre la publication des résultats de la Quality Gate dans les merge requests de GitLab et, enfin, de réduire la consommation de mémoire pour l'image des services Premium. Chaque livraison d'AUTOM/DEVOPS contient plusieurs composants ayant chacun son propre numéro de version. Vous pouvez les consulter dans nos release notes version par version.

À l'occasion de la sortie prochaine de la version 6.0 de Squash TM, prévue pour novembre 2023, la version de Java est mise à jour. En conséquence, Squash TM 6.0 ne sera pas compatible avec Java 11 (Java installé sur la machine hébergeant Squash TM). La version recommandée est Java 17. Vous pouvez également utiliser OpenJDK. Nous recommandons de réaliser la montée de version de Java avant d'envisager un upgrade en version 6.0 de Squash TM.

Il était possible, dans les versions précédentes de l'Orchestrateur Squash, de définir la durée de la période de rétention de tous les workflows. Mais ce mécanisme était parfois trop limité, par exemple pour les équipes qui souhaitaient conserver les informations sur les workflows pendant un jour, sauf pendant les week-ends, pendant lesquels elles voulaient étendre la période de rétention jusqu'à trois jours. Cette nouvelle livraison ajoute la prise en charge des politiques de rétention, chacune étant définie par un champ d'application, une période de rétention et un poids. Les champs d'application définissent les workflows pour lesquels une politique s'applique, ce qui permet, par exemple, de conserver les workflows ayant échoué pendant une période plus longue, d'allonger la période de rétention pendant les week-ends, de configurer des politiques différentes en fonction d'un espace de noms... Les poids sont utilisés lorsque le nombre total de workflows dépasse le nombre maximum de workflows stockables, auquel cas les workflows les plus anciens ayant le poids le plus faible seront supprimés. La quality gate avec seuils introduite le mois précédent est maintenant capable d'exploiter les métadonnées de Squash TM : importance, nature, type, UUID... d'un cas de test ; itération/suite de test ; champs et ensembles de données personnalisés... Mais seule la version 6.0 de Squash TM (qui sera publiée cet automne) fournira entièrement ses métadonnées à l'Orchestrateur Squash. En attendant, avec les versions de Squash TM actuellement disponibles, uniquement la technologie de test, les tags de l'environnement d'exécution et le nom du workflow du job (lorsque Squash DEVOPS est utilisé) peuvent être utilisés pour définir le champ d'application d'une règle pour une quality gate. Les détails sont disponibles dans la documentation mise à jour de Squash DEVOPS. Les commandes d’opentf-ctl relatives aux quality gates ont été améliorées. Comme d'habitude, certains logs ont été clarifiés. Nous avions initialement prévu de livrer une image services Premium consommant moins de mémoire. Mais nous avons rencontré des défis techniques inattendus, et celle-ci est donc reportée à 2023-09. Pour rappel, les nouvelles versions de Squash AUTOM et DEVOPS sont livrées mensuellement (sauf en août). Chaque livraison d'AUTOM/DEVOPS contient plusieurs composants ayant chacun son propre numéro de version. Vous pouvez les consulter dans nos release notes version par version.

La « quality gate », telle que définie dans Squash DEVOPS, est un mécanisme permettant de configurer si un pipeline CI/CD doit continuer ou s'arrêter en fonction des résultats des tests automatisés. Une telle quality gate peut être utilisée, par exemple, pour exécuter de longs tests d'interface utilisateur seulement si tous les tests d'API sont réussis, pour déployer une version candidate sur un environnement de test de recette seulement si peu de tests d'interface utilisateur échouent... Dans la version précédente, l’Orchestrateur Squash ne prenait en charge que deux modes lors de la configuration d'une quality gate : un mode strict qui considère la quality gate comme en succès seulement si tous les tests sont réussis ; un mode passant pour lequel la quality gate est toujours en succès quel que soit le statut des tests. Il est maintenant possible de définir une quality gate avec certains seuils : la quality gate est configurée en fournissant une liste de critères, chaque critère étant défini par un pourcentage de réussite minimal qui doit être atteint pour un type de test donné (par exemple, les tests Postman doivent être en succès à 100 % et au moins 90 % des tests Cypress doivent être en succès). Afin de simplifier la rédaction des critères, de nouvelles fonctions ont été ajoutées dans la syntaxe de l’Orchestrateur : contains, startsWith, endsWith, toJSON et fromJSON. Ce mécanisme sera amélioré dans la livraison 2023-07 en permettant l'utilisation des données de Squash TM (champs personnalisés, nature ou importance du cas de test...) dans la définition du type de tests à considérer pour un seuil donné. Les hooks peuvent désormais être définis pour être appliqués juste avant ou juste après le setup (c'est-à-dire la création de l'espace de travail d'exécution) et le teardown (c'est-à-dire la clôture de l'espace de travail) d'un job. Ces hooks permettront, par exemple : d'utiliser un espace de travail donné, au lieu d'en créer un nouveau comme c'était toujours le cas dans les versions précédentes de l’Orchestrateur Squash, en spécifiant cet espace de travail dans le setup du hook « before » d'un job ; de préserver l'espace de travail, au lieu de le supprimer, en spécifiant de le conserver dans le teardown du hook « before » d'un job . Afin de réduire davantage la consommation de mémoire et de faciliter la prise en charge future de nouvelles technologies de test, les parsers pour interpréter les rapports Surefire pour chaque technologie (JUnit, Cucumber, Cypress...) ont été remplacés par un unique parser configurable. Celui-ci est configuré pour les technologies de test actuellement supportées par l’Orchestrateur Squash, mais cette configuration peut facilement être étendue à une nouvelle technologie de test générant des rapports Surefire. Les utilisateurs qui souhaitent ajouter le support de leur propre technologie n'auront plus besoin d'écrire un microservice de parser. Pour rappel, les nouvelles versions de Squash AUTOM et DEVOPS sont livrées mensuellement (sauf en août). Chaque livraison d'AUTOM/DEVOPS contient plusieurs composants ayant chacun son propre numéro de version. Vous pouvez les consulter dans nos release notes version par version.

La livraison de Squash AUTOM et Squash DEVOPS 2023-05 est disponible : La nouvelle version de l'Orchestrateur Squash nécessite beaucoup moins de mémoire vive que les versions précédentes : 2 Go devraient être alloués au conteneur au lieu de 5 Go pour les versions précédentes. Nous prévoyons de réduire encore les besoins en mémoire dans les prochaines versions. Le support de Cypress a également été amélioré : les captures d'écran générées lors d'un test sont désormais collectées et transférées sous forme de fichiers .tar dans Squash TM. Enfin, les logs ont été améliorés pour faciliter l'analyse des anomalies : toutes les steps ont maintenant un ID, l'Orchestrateur en générant s'ils n'ont pas été spécifiés dans le PEaC ; une notification est générée pour chaque step, elle contient l'ID, le résultat et la conclusion de la step ; les logs du channel SSH sont moins verbeux. Pour rappel, les nouvelles versions de Squash AUTOM et DEVOPS sont livrées mensuellement (sauf en août). La livraison 2023-06 ajoutera le support des hooks pour les jobs. Chaque livraison d'AUTOM/DEVOPS contient plusieurs composants ayant chacun son propre numéro de version. Vous pouvez les consulter dans nos release notes version par version.