Une nouvelle offre Squash On Demand a été lancée à la rentrée pour vous donner l'opportunité de tester librement Squash et Jira Cloud sur une instance dédiée pour 10 utilisateurs, pendant 30 jours. Pour cela, il suffit de remplir un simple formulaire. Une fois les 30 jours d'essai passés, vous pourrez souscrire l'abonnement qui vous convient le mieux ou prolonger l'essai en connectant Squash à votre Jira. Pour rappel, cette offre ne concerne que Jira Cloud. Pour interfacer Squash et Jira Server, vous pouvez utiliser Xsquash, un plugin gratuit, téléchargeable sur la marketplace Atlassian et testable en ligne en suivant notre tutoriel.

Lors du Club Utilisateurs Squash du 19 novembre 2020, nous vous avons présenté la nouvelle offre 2021 autour de la suite logicielle Squash. Cela avait également marqué l’occasion de vous révéler la sortie à venir de l’orchestrateur Squash, un nouvel outil destiné à remplacer Squash TF pour l’exécution de tests automatisés et dont les composants sont répartis au sein des modules Squash AUTOM et Squash DEVOPS. Nous avions alors prévu la sortie de ces composants dans le courant du premier trimestre 2021 mais nous avons pris du retard sur notre planning. Afin de vous proposer une première version Release des fonctionnalités de Squash AUTOM et Squash DEVOPS avec un niveau de qualité correspondant à nos standards, la date de sortie de celle-ci est décalée à début avril 2021. D’ici là, nous vous proposons deux versions alpha aux fonctionnalités bridées, destinées à des POC et donc utilisables dans un contexte hors production (notamment avec un Squash TM dont la base de données est neuve ou la réplication d’une base existante). Plan de sortie Squash AUTOM : 05 février 2021 : version 1.0.0.alpha1 de Squash AUTOM Grâce à cette version, vous pourrez utiliser Squash AUTOM pour : o Créer des plans d’exécution « as code » (PEAC) pour orchestrer précisément l’exécution des tests automatisés en dehors du référentiel de test o Exploiter les actions suivantes au sein d’un PEAC : Récupérer des scripts automatisés depuis un gestionnaire de code Git Déclencher des tests automatisés Robot Framework ou JUnit Transmettre les rapports d’exécutions vers un conteneur Amazon S3 o Transmettre à Squash TM les résultats et les rapports en fin d’exécution d’un plan d’exécution Squash TM. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. Les limitations de la version 1.0.0.alpha1 à retenir : o Pour la récupération des scripts automatisés depuis un gestionnaire Git, ceux-ci doivent être situés dans un repository avec accès en lecture publique et être localisés sur la branche master. o Le déclenchement d’un plan d’exécution de tests automatisés depuis Squash TM via l’orchestrateur Squash n’est pas supporté. La version 1.0.0.alpha1 de Squash AUTOM est compatible avec la version 1.22.1 de Squash TM. 16 mars 2021 : version 1.0.0.alpha2 de Squash AUTOM Grâce à cette version, vous pourrez utiliser Squash AUTOM pour : o Créer des plans d’exécution « as code » (PEAC) pour orchestrer précisément l’exécution des tests automatisés en dehors du référentiel de test o Exploiter les actions suivantes au sein d’un PEAC : Déclencher des tests automatisés Robot Framework, JUnit, Cucumber, Cypress, SoapUI Transmettre les rapports d’exécutions vers un conteneur Amazon S3 o Transmettre à Squash TM les résultats et les rapports en fin d’exécution d’un plan d’exécution Squash TM. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. o Déclencher un plan d’exécution avec tests automatisés depuis Squash TM via l’orchestrateur Squash. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. o Générer un rapport synthétique User Friendly (format Allure) à la fin de l’exécution d’un plan d’exécution récupéré depuis Squash TM. La version 1.0.0.alpha2 lève certaines des limitations de la version 1.0.0.alpha1 : o Pour la récupération des scripts automatisés depuis un gestionnaire Git, ceux-ci peuvent être situés dans un repository avec accès en lecture privée et la branche à utiliser est configurable. o Lors de l’exécution d’un plan d’exécution de Squash TM, les tests Robot Framework, Cypress et Cucumber sont capables d’exploiter les paramètres transmis par Squash TM. Cette version 1.0.0.alpha2 de Squash AUTOM/Squash DEVOPS est compatible avec la version 1.22.2 de Squash TM. 23 avril 2021 : version 1.0.0.RELEASE de Squash AUTOM Grâce à cette version, vous pourrez utiliser Squash AUTOM pour : o Créer des plans d’exécution « as code » (PEAC) pour orchestrer précisément l’exécution des tests automatisés en dehors du référentiel de test o Exploitez les actions suivantes au sein d’un PEAC : Déclencher des tests automatisés Robot Framework, JUnit, Cucumber, Cypress, SoapUI, Agilitest(la compatibilité avec Agilitest n’est disponible qu’avec Squash AUTOM Premium) Transmettre les rapports d’exécutions vers un conteneur Amazon S3 o Transmettre à Squash TM les résultats et les rapports en fin d’exécution d’un plan d’exécution Squash TM. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. o Déclencher un plan d’exécution avec tests automatisés depuis Squash TM via l’orchestrateur Squash. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. o Générer un rapport synthétique User Friendly (format Allure) à la fin de l’exécution d’un plan d’exécution récupéré depuis Squash TM. La version 1.0.0.RELEASE de Squash AUTOM est compatible avec la version 1.22.2 de Squash TM. Plan de sortie Squash DEVOPS : 05 février 2021 : version 1.0.0.alpha1 de Squash DEVOPS Grâce à cette version, vous pourrez utiliser Squash DEVOPS pour : o Déclencher un PEAC depuis un pipeline Jenkins o Récupérer un plan d’exécution de Squash TM contenant des tests automatisés avec, en fin d’exécution, transmission des résultats d’exécutions et des rapports à Squash TM. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. Les limitations de la version 1.0.0.alpha1 à retenir : o Lors de la récupération d’un plan d’exécution de Squash TM, La transmission de paramètres par Squash TM n’est possible qu’avec Robot Framework La version 1.0.0.alpha1 de Squash DEVOPS est compatible avec la version 1.22.1 de Squash TM. 16 mars 2021 : version 1.0.0.alpha2 de Squash DEVOPS Grâce à cette version, vous pourrez utiliser Squash DEVOPS pour : o Déclencher un PEAC depuis un pipeline Jenkins o Récupérer un plan d’exécution de Squash TM contenant des tests automatisés avec, en fin d’exécution, transmission des résultats d’exécutions et des rapports à Squash TM. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. La version 1.0.0.alpha2 lève certaines des limitations de la version 1.0.0.alpha1 : o Pour la récupération des scripts automatisés depuis un gestionnaire Git, ceux-ci peuvent être situés dans un repository avec accès en lecture privée et la branche à utiliser est configurable. o Lors de la récupération d’un plan d’exécution de Squash TM, les tests Robot Framework, JUnit, Cypress, Agilitest et Cucumber sont capables d’exploiter les paramètres transmis par Squash TM. Cette version 1.0.0.alpha2 de Squash DEVOPS est compatible avec la version 1.22.2 de Squash TM. 23 avril 2021 : version 1.0.0.RELEASE de Squash DEVOPS Grâce à cette version, vous pourrez utiliser Squash DEVOPS pour : o Déclencher un PEAC depuis un pipeline Jenkins o Récupérer un plan d’exécution de Squash TM contenant des tests automatisés avec, en fin d’exécution, transmission des résultats d’exécutions et des rapports à Squash TM. Cette fonctionnalité est accessible en version Community ou en version Premium si vous possédez la licence Squash correspondante. La version 1.0.0.RELEASE de Squash DEVOPS est compatible avec la version 1.22.2 de Squash TM. Retrouvez ci-dessous deux tableau résumant les dates de mise à disposition des différentes fonctionnalités de Squash AUTOM et Squash DEVOPS. Retrouvez plus de détails sur les composants de Squash AUTOM et Squash DEVOPS sur nos pages « Roadmap & Release Squash AUTOM » et « Roadmap & Release Squash DEVOPS ». Comment accéder aux composants Squash AUTOM / Squash DEVOPS de la version alpha ? Les composants faisant partie de l’offre Community sont accessibles depuis notre page « Téléchargements ». Pour accéder aux composants faisant partie de l’offre Squash AUTOM Premium ou de l'offre Squash DEVOPS Premium, ou pour toute demande de démonstration ou d’aide à la mise en place d’un POC, vous pouvez nous contacter via ce formulaire en précisant votre besoin.

Publiées le 05 février 2021, les versions alpha de Squash AUTOM et Squash DEVOPS ont pour but de vous donner un premier aperçu des fonctionnalités de Squash AUTOM et Squash DEVOPS, en vous permettant notamment de tester celles liées au pilotage de plans d’exécutions multi-technologies Squash TM depuis un pipeline Jenkins. Ces nouvelles versions sont destinées à une utilisation dans un cadre de POC et, de ce fait, doivent être utilisées avec un Squash TM dont la base de données n’est pas celle utilisée dans votre environnement de production (nouvelle base ou réplication d’une base existante). Pour retrouver plus de détails sur le contenu de ces versions 1.0.0.alpha1, n’hésitez pas à aller consulter notre news dédiée aux sorties à venir pour Squash AUTOM et Squash DEVOPS ou à visiter nos pages « Roadmap & Release Squash AUTOM » et « Roadmap & Release Squash DEVOPS » . La liste de composants mis à disposition est la suivante : Squash AUTOM version 1.0.0.alpha1 : o Image Docker de l’orchestrateur Squash composée d’un ensemble de micro-services o Plugin Result Publisher pour Squash TM (version Squash AUTOM Community et Squash AUTOM Premium). Ce plugin est compatible avec Squash TM 1.22.1. Squash DEVOPS version 1.0.0.alpha1 : o Micro-service Squash TM Generator pour l’orchestrateur Squash (version Squash DEVOPS Community et Squash DEVOPS Premium). Ce micro-service est inclus dans l’image Docker de l’orchestrateur Squash version 1.0.0.alpha1 (voir section Squash AUTOM) o Plugin Test Plan Retriever pour Squash TM (version Squash DEVOPS Community et Squash DEVOPS Premium). Ce plugin est compatible avec Squash TM 1.22.1. o Plugin Squash DEVOPS pour Jenkins. Les composants de la version 1.0.0.alpha1 faisant partie de l’offre Squash AUTOM Community ou de l'offre Squash DEVOPS Community sont disponibles en libre téléchargement depuis notre page « Téléchargements ». Pour accéder aux composants faisant partie de l’offre Squash AUTOM Premium ou de l'offre Squash DEVOPS Premium, ou pour toute demande de démonstration ou d’aide à la mise en place d’un POC, veuillez nous contacter via ce formulaire en précisant votre besoin. Enfin, dans le cadre de la sortie de ces versions alpha, deux sections dédiées nommées "version alpha" ont été créées au sein des catégories Squash AUTOM et Squash DEVOPS de notre forum Squashtest. N’hésitez pas à intervenir dessus pour poser des questions sur l’installation ou le fonctionnement de ces versions.

Bibliothèque des exigences : Bibliothèque des cas de test : Les pas de test d'un cas de test : Bibliothèque des campagnes de test : Exécutions des tests (plan d'exécution d'une itération) : L'interface d'exécution optimisée (IEO) :

Cet article décrit la procédure générale pour monter de version. Des particularités peuvent s’appliquer lors de la montée vers certaines versions (modification des fichiers de configuration, des propriétés). Merci de consulter notre wiki pour savoir quelles sont les versions concernées. Pour monter de version : 1. Arrêter Squash TM. 2. Sauvegarder la base de données (la procédure dépend du type de base), les fichiers de configuration du répertoire ‘conf’ qui ont été modifiés et le fichier de démarrage. 3. Mettre à jour le schéma de la base de données : il faut passer tous les scripts BDDtype-upgrade-to-xxx.sql (présents dans le répertoire ‘database-scripts’) dont le numéro xxx est supérieur à la version à mettre à jour, pour le type de base de données concerné. Il faut les passer dans l’ordre et ne pas passer des scripts d’un autre type de base de données. 4. Installer la nouvelle version de Squash TM. 5. Récupérer les fichiers de configuration et de démarrage sauvegardés à l’étape 2 et les importer dans le répertoire d’installation de la nouvelle version. Un copier/coller des fichiers est suffisant, sauf dans le cas où une modification est apparue dans ces fichiers au changement de version ou que de nouvelles configurations sont requises. 6. Relancer Squash TM. 7. Dans Squash TM, en tant qu’administrateur, lancer une indexation de la base de données : depuis la page d’accueil de l’administration, cliquer sur [Index] puis [Tout indexer]. Il est recommandé de demander aux utilisateurs de vider le cache de leur navigateur après chaque montée de version.

Des plugins (connecteurs à des bugtrackers et rapports supplémentaires) sont disponibles sur la page de téléchargement. Pour les installer sur Squash TM : 1. Arrêter Squash TM 2. Décompresser l’archive du plugin (.zip ou .tar.gz) 3. Copier le contenu du répertoire ‘plugins’ de cette archive dans le répertoire : C:\\squash-tm\plugins pour Windows /usr/share/squash-tm/plugins pour Debian/Ubuntu /usr/lib/squash-tm/plugins/ pour Redhat/Centos /opt/squash-tm/plugins pour un tarball 4. Redémarrer Squash TM

A l'occasion de l'Open World Forum (OWF), Florent Zara, Président de l'édition 2014 et CTO Hénix, répond aux questions du Journal du Net. Programme de l'OWF, tendances, Open data, Open source ou encore internet des objets sont passés en revue dans cet entretien que vous pouvez découvrir ici.

La version 1.14.0 de Squash TM est disponible en téléchargement. Son principal apport, invisible à l'utilisateur, consiste à introduire JPA dans le code de Squash, afin de maintenir l'architecture interne de Squash à jour. Voici les nouvelles fonctionnalités et évolutions apportées à cette version (le numéro indique l'anomalie au sein de Mantis) : Nouveau rapport : Bilan d'itération (licence commerciale) Nouveau rapport : Bilan de campagne (licence commerciale) 5416 : Afficher un dashboard sur la page d’accueil 5421 : Copier/Couper/coller/Déplacer un élément de reporting 5470 : Afficher le bouton [Créer une nouvelle version] lorsque l'exigence est associée à un jalon verrouillé 5488 : Exporter un élément de reporting en format image 5489 : Permettre l'import de fichiers au format XLSM Drag'n'drop pour l'ajout d'éléments dans les listes depuis l'arbre de la bibliothèque (exigences rattachées, cas de test dans une itération par exemple) 6084 : Forcer la base MySQL en mode InnoDB à la création 6160 : Le bouton "retour" depuis les pièces jointes des pas de test ramene sur les pas de test 6223 : Ajout d'une colonne dans le tableau des exécutions, indiquant le %age de pas de test exécutés et OK pour chaque cas de test 6229 : ordre alphabétique des utilisateur à affecter dans une anomalie Mantis 6275 : Gestion du périmètre des données d'un graphique personnalisé optimisé Saisie d'un JDD sans nom : on ne perd plus la saisie si on oublie de mettre un nom au JDD La création d'une nouvelle version d'exigence associée à un jalon verrouillé est maintenant possible Cette version corrige un certain nombre de bugs : 5380 : suppression d'un utilisateur ayant créé un jalon 5480 : comportement identique de la simulation de l'import et de l'import effectif 6062 : performances améliorées dans la gestion des anomalies connues 6081 : suppression d'un utilisateur ayant créé un rapport 6085 : autoconnect avec le bugtracker réparé 6148 : Présentation des jeux de données par ordre alphabétique lors de l'appel d'un cas de test dans un cas de test 6156 : les recherches sur des objets créés à 00:00 considèrent qu'ils datent de la veille 6209 : détection des jalons lors de l'ajout du contenu d'un dossier à un plan d'exécution 6217 : Ecran espace "campagne" vide après avoir cliqué sur le bouton [Retour] 6235 : Les tags projets bugtracker si un projet Squash est rattaché à plusieurs projets dans le bugtracker

L’espace Pilotage permet de créer des éléments de reporting tels que des graphiques ou des tableaux de bord personnalisés. Ils peuvent porter sur les différentes entités de l’application (exigences, cas de test, campagnes, itérations, exécutions…) et sur les attributs (criticité, catégorie, statut d’exécution, créé le, champs personnalisés…) qui leur sont associés. Dans cet article, nous abordons pas-à-pas les différentes étapes de création d’un graphique en nous appuyant sur un cas concret. La création de graphique se fait en plusieurs étapes à l’aide d’un assistant qui guide l’utilisateur. L’exemple suivant montre la création d’un graphique qui permet de comparer pour des criticités d’exigences prédéfinies les statuts d’exécution des cas de test qui leur sont associés. La création de graphique se fait en plusieurs étapes à l’aide d’un assistant qui guide l’utilisateur. Étape 1 : Sélection du périmètre Le périmètre définit les données sur lesquelles le graphique va porter : a. Périmètre par défaut : graphique créé à partir des objets (Exigences, Cas de test, Exécutions) du projet dans lequel se trouve le graphique. Si le graphique est amené à être déplacé ou copié, le périmètre s'adaptera au projet de destination. b. Sélection de projets : graphique créé à partir des objets d’une sélection d’un ou plusieurs projets. Si le graphique est amené à être déplacé ou copié, le périmètre ne sera pas modifié. c. Sélection personnalisée : graphique créé à partir des Exigences, des Cas de test ou des Exécutions que l'on aura sélectionnés. Les objets considérés pour obtenir le graphique seront ceux reliés à tous les objets sélectionnés à cette étape, sans tenir compte de leur appartenance à un projet. Dans cet exemple, nous choisirons « Périmètre par défaut » Étape 2 : Sélection des entités et attributs Nous souhaitons créer un graphique mettant en relation la criticité des exigences et les statuts d’exécution. Il faut donc sélectionner : a. L’entité « Versions d’exigences » avec les attributs « Criticité » et « ID de version d’exigence » (qui permettra d’effectuer une opération de comptage sur les exigences), b. L’entité « Exécutions » avec l’attribut « Statut d’exécution ». Étape 3 : Sélection des filtres Nous souhaitons limiter les données du graphique aux criticités « Critique », « Majeure » et « Mineure ». Il faut donc cocher la case « Criticité », sélectionner « Dans » dans le menu déroulant et sélectionner « Critique », « Majeure » et « Mineure » (CTRL + clic). C’est le seul filtre à appliquer pour notre exemple, il n’est pas nécessaire de toucher aux autres attributs. Étape 4 : Sélection des opérations Différentes opérations peuvent s’appliquer en fonction des attributs. Dans cet exemple, nous appliquerons des opérations de comptage et d’agrégation : Comptage : compte le nombre d'objets sélectionnés via le périmètre et les filtres, correspondant à chaque croisement de valeur de Criticité et de Statut d'Exécution, Agrégation : permet de grouper les entités par valeur de leurs attributs Nous sélectionnerons ainsi : Pour « ID de version d’exigence » : « Comptage » (les exigences ayant toutes des ID différents, il y aura autant de valeurs distinctes qu’il y aura d’exigences). Pour « Criticité » : « Agrégation » (puisque nous voulons croiser les valeurs de criticité "Critique", "Majeure" et "Mineure" avec...). Pour « Statut d’exécution » : « Agrégation » (...celles de Statut d'Exécution). Étape 5 : Sélection du type de graphique Nous souhaitons créer un graphique de type « Comparaison », il faut donc sélectionner cette option. Il est également nécessaire de sélectionner les données qui figureront sur les axes. Les données sélectionnables varient selon le type de graphique, l’axe et le type d’opération associés. Dans cet exemple : Axe 1 : sélectionner « Criticité » (opération de type agrégation) Axe 2 : sélectionner « ID de version d’exigence » (opération de type comptage) Séries : sélectionner « Statut d’exécution » (opération de type agrégation) Attention : pour ce type de graphique, et pour ce type seulement, les petites flèches qui indiquent si l'on parle de l'axe horizontal ou de l'axe vertical sont inversées. Étape 6 : Aperçu Ajouter un titre au graphique et enregistrer. L'ajout d'un titre est obligatoire. Si vous enregistrez et qu'il ne se passe rien, pensez à vérifier que vous avez bien donné un titre au graphique. Le graphique et ses informations s’affichent dans le projet dans lequel il a été créé : Si le graphique est copié ou déplacé dans un autre projet, les données s’adapteront au projet de destination (ce n’est possible que si le graphique a un périmètre par défaut). Utilisation des Dashboards dans les espaces Les dashboards, collections de graphiques personnalisés, peuvent être utilisés dans les espaces Exigences, Cas de test ou Exécutions. Ils remplacent alors les tableaux de bord par défaut proposés par Squash. Quel que soit le périmètre défini à la création des graphiques du dashboard, il sera remplacé par l'option "Sélection personnalisée", et la sélection considérée sera l'ensemble des objets choisis dans la bibliothèque de gauche. Nous rappelons que dans ce mode, c'est l'ensemble des objets reliés aux objets sélectionnés qui forment le périmètre. Une Exigence est liée à un Cas de test lorsque ce Cas de test vérifie l'exigence, Un Cas de test est lié à une Exécution lorsqu'elle exécute le Cas de Test.

La présence de Henix à la JFTL (Journée Française des Tests Logiciels) le 11 avril dernier, nous a permis de rencontrer Rémi Wasmer, membre de l’équipe de tests chez Globaz. Globaz est une entreprise suisse, spécialisée dans l'informatique des assurances sociales. La société réalise, installe et héberge des solutions clef en main dans les domaines de l'assurance-vieillesse et survivants (AVS), des allocations familiales (AF), de l'assurance-invalidité (AI) et de l'assurance immobilière (ECA). Le rôle de l’équipe de Rémi Wasmer au sein de Globaz est d’organiser et d’assurer la validation fonctionnelle des solutions mis à disposition de leurs clients. Depuis plusieurs mois, Globaz utilise l’outil de gestion de patrimoine de tests publié par Henix, Squash TM,  pour une optimisation de son processus de validation de solutions. Rémi Wasmer a accepté de revenir sur son expérience Squash : les raisons pour lesquelles ils ont adopté Squash TM et les bénéfices pour son équipe au quotidien. Quel est aujourd'hui l'enjeu majeur de vos équipes QA au sein de l'entreprise Globaz ? Nos équipes QA interviennent principalement dans le cadre de la validation des solutions applicatives qui sont éditées par nos équipes (solution en TMA (Tierce Maintenance Applicative) avec des enjeux forts d’évolutions légales), ainsi que sur la validation de l’infrastructure mise à disposition de nos clients dans le cadre de l’hébergement de leur IT (postes de travail et serveurs). Dans ce cadre, l’enjeu est d’assurer un haut niveau de disponibilité des prestations que nous délivrons à nos clients (infrastructure et solutions) allant jusqu’à 24/7 pour certains d’entre eux. Il n’est pas envisageable pour notre entreprise de mettre en production un service qui ne permet pas d’assurer le travail quotidien des utilisateurs finaux, d’où la nécessité d’avoir un processus de validation maîtrisé et reproductible. Dans quel cadre avez-vous fait appel à la société Henix ? Le patrimoine de tests associé aux services délivrés étant relativement conséquent (certaines solutions éditées ont plus de 15 ans), il était devenu indispensable d’industrialiser en détail le processus de validation fonctionnelle et technique. Squash TM nous permet de garantir un cadre et une traçabilité de notre processus de validation et de travailler sur son efficience avec des coûts et des choix maîtrises. Comment avez-vous connu Squash TM ? Dans le cadre de l’amélioration de nos processus internes, nous avons réalisé des POC sur plusieurs logiciels Open Source de gestion d’exigences et de cas tests. Au terme de l’évaluation, le produit Squash TM a été retenu pour nos phases de validation. Ce choix a également été partagé avec nos clients. Quels sont les principaux avantages de cet outil ? Les principaux avantages que nous avons retenus sont les suivants : La gestion des bibliothèques de tests et des campagnes dans un espace collaboratif nous permet de mieux partager, cibler et définir les périmètres de tests. Cela facilite l’attribution des cas tests, leur maintien, ainsi que la gestion et traçabilité de nos tests de non-régressions.Squash TM nous permet de travailler sur différents projets avec nos clients et dans un même outil. Ainsi, nous pouvons consolider nos actions et résultats à tout moment et piloter plus facilement nos projets de validation.La gestion des anomalies et l’interfaçage avec un produit de ticketing tiers (en l’occurrence Jira chez Globaz), nous permet d’interagir efficacement avec nos équipes de réalisation, sans avoir à gérer des informations dans des outils distincts et adresser des problèmes de synchronisation qui en résultent. Quelles ont été les différentes étapes d'intégration de Squash TM auprès de vos équipes (formations, conduite du changement, etc..) ? La réalisation des POC a été faite par une équipe qui présentait des compétences multiples (équipe transverse), et qui a exposé les résultats des différents produits évalués aux équipes projet et management. Nous abandonnions un produit qui ne présentait que peu de facilité de collaboration pour un outil abouti, déjà dans ses premières releases, ce qui a su convaincre rapidement les différentes parties prenantes. Elles ont notamment été convaincues de l’intérêt de centraliser, consolider et gérer le processus de validation des projets avec un outil moderne – qui présente également un potentiel d’évolutions intéressant – et offrant une capacité de reporting en temps réel particulièrement pertinente. Un projet interne a permis d’utiliser Squash TM en condition réelle (une formation a été conduite auprès des participants au projet). Enfin, suite à l’expérience réalisée, l’utilisation de Squash TM a été généralisée et le produit est utilisé comme unique outil de validation interne. Quel est le prochain axe de développement majeur ? Le prochain axe de développement de nos équipes QA sera sans nul doute l’automatisation des tests (tests unitaires, tests de non-régression fonctionnels, tests de charge et tests de sécurité) pour la validation de nos futures solutions avec une centralisation de la gestion de cet aspect d’automatisation. Le rythme de production et les exigences en termes de qualité des solutions éditées est en constante augmentation, ce qui induit un besoin d’automatisation fort – optique DevOps, mais pragmatique et adapté au besoin réel de notre marché. L’histoire est donc à suivre ! Nous remercions Rémi Wasmer d’avoir pris le temps de répondre à nos questions.

Avant de se lancer dans un chantier d’automatisation, il est recommandé d’éprouver la faisabilité et l’opportunité du projet afin d’évaluer la pertinence des outils dans le contexte de l’entreprise, le patrimoine de tests à automatiser et les gains du projet. Cette étude passe notamment par ce qu’on appelle une preuve de concept, ou un POC (Proof of concept) d’automatisation. Cet article reprend les grandes étapes de l’étude préalable à l’automatisation et répond plus particulièrement aux problématiques éprouvées par le POC lors de la mise en place d’un chantier d’automatisation de test : à quelle étape le POC intervient dans le projet d’automatisation, quels en sont les enjeux, le processus et les bonnes pratiques. 1. Définition d'un POC d'automatisation 2. Enjeux d'un POC d'automatisation 3. Restitution des résultats aux décideurs 4. Les bonnes pratiques pour la réussite d'un POC Définition d’un POC d'automatisation Le POC d’automatisation des tests est une des étapes préliminaires à la mise en place d'un projet d'automatisation des tests. Dans le cycle d’achat, le POC permet à l’entreprise de mieux se focaliser sur les sujets importants, de créer les conditions pour une meilleure prise en main des utilisateurs, d’initier le changement, d’implémenter les bonnes pratiques et de poser les bases d’un déploiement réussi. Il se focalise de manière plus pratique aux problématiques liées au contexte du client, permettant ainsi de mesurer plus efficacement l’opportunité d’un projet d’industrialisation en fonction du contexte organisationnel, technique et applicatif. Enjeux d’un POC d'automatisation Le processus de développement des tests automatisés est un chantier fastidieux qui requiert de l’investissement et de la rigueur pour les équipes de développement. Une étude préalable est nécessaire afin de planifier la stratégie à mettre en place. Le POC permet d’adresser tout ou partie des principales problématiques liées à la mise en place d’un projet d’automatisation : 1) La stratégie d’automatisation Objectif - Étudier l’éligibilité du patrimoine de test à l'automatisation, planifier la réorganisation des équipes, la montée en compétence, prévoir l’intervention d’experts tiers… Il est tout d’abord primordial de prendre connaissance du contexte et d’analyser le référentiel de test existant pour vérifier que le patrimoine de tests existant est adéquat aux besoins de l’automatisation (granularité des cas de test, catégorisation des cas de test (TNR, intégration)). Élaborer une stratégie d’automatisation permettra également d'identifier les pré-requis et les impacts liés à la mise en œuvre de l’automatisation (plan de remédiation sur le patrimoine de tests, définition des compétences nécessaires à l’automatisation, organisation cible, environnement de développement, etc.) 2) L’étude de faisabilité technique Objectif - Faire les bons choix techniques Cette étape vérifie que les tests sont éligibles techniquement à l’automatisation (choix des automates compatibles pour interagir avec le SUT, utilisation de proxy, etc.). Cela consiste à prendre un échantillon représentatif des cas de test repérés et à réaliser les scripts automatiques associés. L’étude permet d’évaluer la complexité technique de mise en œuvre (installation d’un environnement dédié, scripting, préparation des jeux de données, paramétrage, variabilité, orchestration, enjeux de sécurité) et de calculer le retour sur investissement pour l’échantillon de référence. 3) L'étude d’opportunité Objectif - Calculer le ROI, les gains en termes de qualité et de délai dans le cycle de développement, budgétiser l’investissement en matériel et ressources humaines… L’étude d’opportunité permet de calculer les différents gains auxquels conduit l’automatisation des tests sur le périmètre choisi en termes de : Temps - Délai de mise en production Qualité - Couverture de test, volume d’exécution de test, tests les plus opportuns à automatiser (stabilité fonctionnelle, technique, temps d’exécution manuel vs automatique, etc.) Financier - ROI Restitution des résultats aux décideurs La restitution des résultats d’un POC d’automatisation permet de sensibiliser les décideurs et de soulever certains points de vigilance avant toute prise de décision finale. Les consultants responsables d’un POC d’automatisation ont également pour mission de conseiller le client et de l’accompagner dans sa prise de décision. La restitution des résultats se fait la plupart du temps lors d'un rendez-vous en présentiel. Elle comprend également la livraison d’un certain nombre de documents, tels que l’étude d’opportunité, la matrice de sélection des tests à automatiser, les scripts automatisés et le bilan de l’étude de faisabilité. La restitution permet aussi de proposer un plan d’automatisation. Les bonnes pratiques pour la réussite d’un POC Fournir au client les pré-requis pour un bon POC (préparation de l’environnement, système sous test dédié à l’automatisation (différent de l’environnement de recette)). Bien définir le périmètre du POC. Répondre aux problématiques posées à l’initiation du projet. S’il est validé, un POC d’automatisation de test est suivi de la mise en place des différentes étapes du projet d’automatisation : 1. Définition de l’architecture de la plateforme d’automatisation 2. Mise en place de l’outillage d’automatisation dans une plateforme dédiée 3. Définition du cycle d’automatisation 4. Adaptation de l’organisation des équipes aux nouveaux processus 5. Formation des utilisateurs et de l’ensemble des acteurs aux outils et nouveaux processus 6. Lancement du projet Le temps imparti aux différentes étapes d’un POC d’automatisation dépend évidemment de l’organisation des équipes internes, des outils utilisés et du patrimoine existant. Il existe une estimation pour le POC d’automatisation lorsque l’architecture d’exécution est basée sur l'outil d’industrialisation des tests fonctionnels proposé par Henix pour les chantiers d’automatisation de ses clients. Compréhension du contexte, des enjeux et des besoins : approximativement 2 jours. Étude de faisabilité technique : approximativement 6 jours. En moyenne, 5 tests automatisés sont réalisés pendant l’étude de faisabilité. Ce peut être des tests de Batch, des tests de Web services et/ou des tests d'IHM Web. Étude d’opportunité : approximativement 7 jours. Un POC Squash TA (Test Automation) est composé des 3 phases décrites précédemment. Il est pris en charge par un consultant Henix et dure approximativement 20 jours. Architecture d'un POC, illustrant l'interface avec les différentes briques de la suite Squash :