Vous travaillez (ou envisagez de travailler) en agile avec l’approche BDD grâce à un outil permettant de définir, automatiser et exécuter vos scénarios ? Squash peut répondre à votre besoin. En effet, à partir de la version 1.22, Squash vous offre une nouvelle interface intuitive pour rédiger vos scripts et met à votre disposition une bibliothèque d’actions qui constitueront vos scénarios. Vous pourrez ainsi définir et maintenir un vocabulaire commun partagé entre les différents acteurs de vos projets de test et mutualiser vos implémentations Cucumber ou Robot Framework. Squash vous permet ainsi de : • Formaliser des scénarios structurés en Gherkin qui vont décrire dans le détail, et avec des exemples, les comportements attendus. Il est également possible de les formaliser en les rattachant directement à des US que vous aurez définies (dans Jira via Xsquash). • Mettre ces scénarios à disposition de tous les contributeurs (dans Squash et dans Jira via Xsquash) • Constituer une Bibliothèque d’Actions qui facilitera la rédaction et la maintenance des scénarios en vous laissant la liberté de : ajouter et de supprimer des actions gérer les paramètres de chaque action lister les cas de test utilisant l’action consulter et modifier les informations sur l’implémentation de l’action • Implémenter et exécuter ces scénarios avec Cucumber ou Robot Framework.

Henix a appris avec une profonde tristesse le décès de Laurent Séguin. Acteur incontournable de la communauté du Logiciel Libre, il a beaucoup aidé l'équipe Squash lors de ses premières années et a été un soutien sans faille d'Henix dans son investissement pour le Logiciel Libre (Open World Forum, FUI, Systematic). Nous gardons le souvenir d' une personne engagée, à la fois bienveillante, constructive et attachante. Nous souhaitons lui rendre hommage et nous associer aux voix de toute la communauté pour faire part à sa famille et ses proches de nos condoléances émues.

A partir de début 2021, l’offre Squash évolue pour être divisée en trois produits distincts : Squash TM, pour la gestion du patrimoine de tests, basé sur le fonctionnement de l’outil actuel du même nom Squash Autom, pour les fonctionnalités d'automatisation des tests Squash DevOps, pour l'intégration des tests automatisés et de leurs exécutions dans une chaîne CI/CD L’actuel produit Squash TF se voit ainsi divisé en deux produits (Squash Autom et Squash DevOps) pour renforcer la compatibilité de Squash avec des frameworks d’automatisation existants et aller plus loin dans l’intégration aux chaînes DevOps. L’utilisation de Squash, quel(s) que soi(ent)t le(s) produit(s) choisi(s), repose toujours sur : une version gratuite et fonctionnelle (appelée version Community), ou une version commerciale permettant l’accès à des fonctionnalités avancées ou à des connecteurs spécifiques (appelée version Premium) et dont le prix varie selon le nombre d'utilisateurs Les clients bénéficiaires de la version commerciale de Squash TF se verront proposer le passage aux versions commerciales de Squash Autom et DevOps au même prix. Pour plus de détails sur le contenu de chaque offre, rendez-vous sur notre page dédiée : https://www.squashtest.com/pricing

L'aventure Squash a débuté il y a 10 ans. Voici un retour sur l'évolution de nos stratégies produit et tarifaire et les réflexions qui ont abouti à la sortie de notre nouvelle offre produit, effective à partir de début 2021. Squash TM Sur la partie Test Management, nous nous voulions un outil de test management efficace, agréable à l'utilisation pour les testeurs (en premier lieu ceux de notre société Henix) qui l'utilisent de manière intensive. Nous souhaitions également un outil accessible (ie gratuit pour les petites sociétés, pas trop cher pour les autres) de manière à outiller largement les bonnes pratiques de test et contribuer à la professionnalisation du métier de testeur. Squash TM a été conçu et évolue depuis l'origine dans cette optique, avec des versions trimestrielles puis semestrielles (la 1.22 sortant fin 2020). Au printemps 2021, nous sortirons une version majeure (Squash TM 2.0) avec une ergonomie actualisée (réécriture du front en angular tout en gardant le même back, donc avec montée de version standard). Nos objectifs d'il y a 10 ans sont globalement atteints puisque l'outil s'est diffusé largement (environ 2000 téléchargements par mois) en open source, des grands comptes l'ont adopté comme unique outil de patrimoine de test (jusqu'à 4000+ utilisateurs), les bonnes pratiques de test se sont répandues et au passage l'activité service d'Henix est passée en 10 ans de 50 à 250 personnes. Sur ce module, notre enjeu produit (pour la décade à venir ?) est de continuer à enrichir fonctionnellement sur les axes : positionner davantage les tests au cœur de la conception applicative puis le patrimoine de test comme documentation vivante du patrimoine applicatif, fournir des représentations des tests différentes selon la méthodologie, l'organisation, le cycle de vie projet depuis le langage naturel, structuré (gherkin) interprétable, puis exécutable. Et nous étudions actuellement la possibilité de proposer nous-mêmes un outil intégré de gestion de l'agilité avec un objectif de fourniture d'un nouveau produit Squash_Agile fin 2021 permettant d'outiller Scrum/Kanban et les cadres d'agilité à l'échelle SAFe/LeSS. De Squash TA à Squash Autom et Squash DevOps Sur la partie Automatisation et DevOps, et plus largement le shift-right, notre cheminement a été moins linéaire. Nous voulions initialement proposer un environnement complet de tests automatisés, accessible aux testeurs à goût/potentiel technique comme aux développeurs. En 2012, nous avons donc sorti le module Squash TA qui était à la fois un studio et un environnement d'exécution de tests automatisé. Nous avons alors (lentement) compris 3 choses : Les développeurs ou automaticiens ne nous avaient pas attendu pour choisir leur environnement de développement privilégié (studio) et n'avaient pas d'intention d'en changer. Il est coûteux (et hors de notre expertise native "Qualité Logicielle") de faire un studio "universel" surtout si on veut s'adapter aux spécificités de tous les systèmes sous test. Et surtout l'enjeu 'test' d'une transition digitale réussie n'est pas d'automatiser des tests, mais plutôt d'outiller le process entre le testeur fonctionnel, l'automaticien, le développeur et le devops de manière que le "bon" test soit automatisé au "bon" moment. Concrètement, dans la plupart des Systèmes sous Tests de nos clients (*), notre conviction est que l'optimum économique consiste à automatiser peu, au fur et à mesure que l'application se stabilise en s'assurant que chaque test automatisé sera utile et pourra être maintenu. La bonne manière de s'en assurer est d’intégrer les tests automatisés au pipeline de la CI/CD et de trier entre régression et faux positifs en cours de développement. Nous avons donc sorti fin 2018 Squash TF 1.x qui était un environnement d'exécution de tests automatisés, réutilisant l'architecture de Squash TA. Ce module rencontre aujourd'hui des limites en termes d'architecture qui nous ont incité à le réécrire complètement durant cette année 2020 avec les principes suivants : Architecture micro-service, notamment pour des raisons de déploiement et d'exploitabilité en environnement DevOps. Séparation entre les fonctionnalités permettant d'automatiser (à destination des testeurs et automaticiens) et celles permettant d'intégrer les tests automatisés (pour le gestionnaire de pipeline) au sein de l'usine DevOps. Cela a donc donné naissance à 2 produits (astucieusement) nommés Squash_Autom et Squash_DevOps. Suppression de l'adhérence avec Squash TM de manière à rendre chacun des 3 produits Squash TM, Squash_Autom et Squash_DevOps indépendants. Sur les 2 nouveaux produits, nous cherchons à pouvoir apporter de la valeur, même pour les sociétés ou projets n'utilisant pas Squash TM : L'utilisation de Squash Autom "seul" permet ainsi d'unifier/d'homogénéiser l'usage des différents automates (Selenium, Cypress, SoapUI, Appium...) et des différents studios (Robot Framework, Cucumber, UFT, Agilitest...) tout en générant un format de reporting commun (type Allure) L'utilisation de Squash DevOps "seul" permet d'orchestrer l'ensemble des tests automatisés, de les intégrer au pipeline DevOps (CI/CD) puis de poster les résultats vers les destinataires (le pipeline lui-même, l'outil de patrimoine de test ou le framework de reporting et d'agrégation des résultats de test). Dans toutes ces évolutions, nous avons toujours cherché à garantir une compatibilité ascendante, c'est à dire que des tests écrits avec Squash TA ou Squash TF continuent à fonctionner de version en version et avec l'installation de Squash_Autom et Squash_DevOps. Monétiser, c'est (aussi) pérenniser Nous avons eu la chance de pouvoir lancer et développer le projet pendant longtemps sans vraiment nous soucier de la monétisation, à la fois car nous avons bénéficié de subventions/CIR en 2011-2013 et parce que les retombées futures en termes de réputation pour Henix nous suffisaient. Puis nous avons réalisé, que sans monétisation, nous n'aurions pas les moyens de faire évoluer le produit comme nous l'espérions sur la durée. Nous avons alors tâtonné en expérimentant différents modèles classiques dans le monde Open Source comme la vente de support, la double licence, la licence fixe... Nous avons finalement opté pour un modèle "open core" avec : une version Community gratuite composée d'un cœur open source et de modules freemium une version commerciale, avec souscription annuelle, composée de la version Community et de plugins commerciaux. Dans le choix des fonctionnalités gratuites vs payantes, nous cherchons à positionner le curseur de manière à fournir une version Community pleinement fonctionnelle (non bridée). La version payante (Premium) se différencie avec des connecteurs supplémentaires (vers des outils payants en général) ou bien des fonctionnalités supplémentaires à valeur ajoutée, mais non indispensables, ainsi que le support. Selon nous, l'existence et le maintien de cette version Community (avec le même cœur) limite le "vendor lock in" et permet à nos clients d'avoir le meilleur des contre-pouvoirs en cas d'abus de l'éditeur : repasser sur la version Community en renonçant aux fonctionnalités commerciales. Pour la mécanique tarifaire de Squash TM Premium, nous avons cherché un modèle simple identique, pour le SaaS et la version serveur. Nous avons choisi le modèle de (feu) Jira Server avec des tranches en fonction du nombre d'utilisateurs déclarés, qui nous a semblé à la fois simple à comprendre et à mettre en œuvre. Nous avons opté pour une base tarifaire (en version serveur) de 50 utilisateurs pour 6000 euros (10 euros/utilisateur/mois) inchangée depuis l'origine (avec un coût de 3 à 10* moins cher que notre concurrent historique mais qui nous parait suffisant). Pour les autres modules, Squash Autom et Squash DevOps (qui sont composés de services et non d'applications et où la notion d'utilisateur a moins de sens), nous avons choisi de fixer le prix de la version Premium comme un pourcentage de la base tarifaire de Squash TM (en l'occurrence 75% pour Squash Autom et 75% pour Squash DevOps). Et pour les clients souhaitant utiliser Squash_Autom ou Squash_DevOps en version commerciale sans Squash TM, nous baserons notre tarification en fonction du nombre d'utilisateurs de leur référentiel de test. Les clients actuels de la version commerciale de Squash TF (appelée version Entreprise) se verront proposer les versions Premium de Squash Autom et Squash DevOps sans surcoûts (jusque 2022). Avec l'agilité et le DevOps, le test se positionne au cœur de la fabrication des SI et de la transition digitale, la décennie à venir s'annonce passionnante !!! L'Equipe Produit Squash. (*) Cette remarque concerne les SI actuels de nos clients, caractérisés par beaucoup de lignes de code et une grande sensibilité des tests aux données (c'est différent par exemple sur des architectures de calculateur embarqué ou des architectures pures micro-service ou d'API).

La version 1.22.1 de Squash TM a été publiée dans le courant du mois de janvier 2021, elle propose notamment une API Rest dédiée aux fonctionnalités d’administration, une API Rest incluse dans le plugin Xsquash4Jira, mais aussi des nouvelles fonctionnalités permettant une rédaction simplifiée et intuitive de cas de test au format BDD en vue de leur automatisation. Découvrez-les en images : ✓ API administration* Les fonctionnalités d’administration fonctionnelle de Squash sont maintenant disponibles dans une API Rest dédiée. ✓ Xsquash4Jira Il est désormais possible de configurer le plugin Xsquash4Jira par le biais d’une API Rest incluse dans le plugin Xsquash4Jira (nécessite d’avoir le plugin API Administration). ✓ Xsquash (Server et Cloud) La dernière version de Xsquash prend en compte l’affichage des cas de test au format BDD. Le statut d’automatisation des tests et le nom des jeux de données ont également été ajoutés respectivement aux onglets « Cas de test Squash TM » et « Exécutions Squash TM ». ✓ Gestion des cas de test au format BDD Ce nouveau format de cas de test permet à l’utilisateur de formaliser des scénarios à l’aide d’une interface simple et intuitive. Les cas de test au format BDD se caractérisent par leurs pas de test qui s’appuient sur la syntaxe Gherkin et qui sont composés d’un mot-clé suivi d’une action. Lors de la rédaction des pas de test, l’utilisateur se voit suggérer des actions déjà utilisées dans d’autres cas de test et qui correspondent à ce qu’il a saisi**. Les actions peuvent donc être réutilisées et partagées entre des cas de test issus de différents projets facilitant ainsi leur rédaction et leur maintenance. Les actions peuvent contenir des parties variables qui seront valorisées au sein des pas de test par des valeurs libres ou par les paramètres du cas de test qui pourront ensuite être déclinés en jeux de données. Les pas de test BDD peuvent également contenir des tables de données, des docstrings et des commentaires. ✓ Espace bibliothèque d’actions** Ce nouvel espace, accessible via un plugin, permet de visualiser et gérer l’ensemble des actions présentes dans les cas de test au format BDD, et ce, afin de construire un référentiel cohérent s’appuyant sur un vocabulaire commun. Depuis cet espace, il est notamment possible de consulter les cas de test utilisant une action et les informations relatives à son implémentation. Les fonctionnalités de cet espace sont disponibles dans une API Rest qui est incluse dans le plugin Bibliothèque d’actions**. ✓ Export des scripts associés aux cas de test BDD selon la technologie d’implémentation cible Les scripts associés aux cas de test BDD peuvent être exportés ou transmis à l’automaticien via le plugin Git dans un format qui dépend de la technologie d’implémentation cible, paramétrée au niveau du projet Squash. Le choix de la technologie (Cucumber ou Robot Framework) n’a pas d’impact pour l’utilisateur lors de la rédaction des cas de test, Squash se charge de convertir le script au bon format (.feature ou .robot) en ajoutant les éléments spécifiques à chaque langage. ✓ Consultation des suites automatisées Au niveau des itérations et suites de tests, un nouvel onglet permet de visualiser l’historique des suites automatisées (ensemble de tests automatisés lancés au même moment). Pour chaque suite automatisée, l’utilisateur peut notamment consulter le statut d’exécution global, le détail des tests exécutés et accéder au rapport d’exécution de l’ensemble des tests. ✓ Nettoyage des suites et exécutions automatisées Un nouveau menu permet à l’administrateur de supprimer en masse les suites et exécutions automatisées antérieures à une durée paramétrée au niveau de chaque projet. **Ces fonctionnalités sont accessibles via un plugin inclus dans la licence Squash TM Premium *Ces fonctionnalités sont accessibles via un plugin inclus dans la licence Squash AUTOM Premium Télécharger Squash 1.22.1 et découvrir la release note