Dans un précédent article, nous avions abordé l’enjeu de l’automatisation du patrimoine de tests au sein de l’ICDC (le centre informatique de la Caisse des Dépôts) dont les premiers chantiers étaient initiés en 2009. Aujourd'hui, nous revenons sur le déploiement de Squash TM au sein du processus de validation : les raisons de ce choix et les défis qui en ont découlé. La mise en place de nouveaux outils, et le choix de restructuration de la stratégie de tests s’accompagnent d’un besoin évident de montée en compétences pour les équipes concernées. Suite à la demande de l’ICDC, Henix mobilise ses ressources humaines afin d’encadrer les équipes de tests et apporter son expertise outillage. En charge de mener à bien le déploiement de Squash TM en remplacement de HP QC au sein de l’ICDC, Odile HAULER CHAU, consultante chez Henix, nous expose son retour d’expérience. Quel était votre rôle au sein du projet de déploiement de Squash à l’ICDC ? Arrivée fin janvier 2016 à l'ICDC, mon rôle était de piloter la mise en place de Squash TM en remplacement de l'outil de tests existant, HP QC. Avec la conduite de changement que cela impliquait. L’échéance de la mission, initialement prévue fin juin 2016, fut finalement programmée pour mai 2016. Il a fallu informer les équipes concernées du projet, les accompagner pour préparer les migrations (mappings) et les former pour qu'elles puissent être rapidement opérationnelles. Dans quel contexte s'est déroulée la mission ? L’objectif premier de l’implémentation de Squash TM était de remplacer l'outil de tests HP QC et de pouvoir proposer une suite globale et complète d’outils intégrés dédiés aux équipes projet (Jira comme bugtracker, Confluence, Bitbucket, plateforme d’automatisation avec Squash TA et Mako). Quelles étaient les équipes formées sur la prise en main de Squash ? Les équipes accompagnées étaient des maîtrises d’œuvre, des maîtrises d'ouvrage et des fonctionnels Métier - en fait, toute personne impliquée dans la réalisation et la validation des applications. Toute ces équipes étant réparties sur Paris (5 sites), Angers et Bordeaux. Quels étaient les principaux enjeux sur le déploiement de Squash TM ? Le principal enjeu était l’adoption rapide de Squash TM par l'ensemble des équipes concernées. Squash TM est très facile à prendre en main, de par sa simplicité d'utilisation et son ergonomie user-friendly. Donc la principale difficulté se situait plutôt dans la volonté d'homogénéisation des pratiques concernant la gestion des demandes, ainsi que dans la multiplicité et diversité des équipes impactées d'un point de vue organisationnel et géographique. Quels supports ont été mis en place pour mener à bien la formation des équipes ? Afin d'accompagner les équipes impactées par ce changement, nous avons proposé : 2 formats de formations adaptés aux besoins de chacun : des tutorats de prise en main rapide en deux heures et des formations complètes d'une journée. De l'assistance par mail ou téléphone. De la documentation accessible en ligne : foire aux questions, guide utilisateur et glossaire des termes utilisés dans l'outil. Quel est le résultat retenu ? L'implémentation de Squash TM en remplacement de l'ancien outil, et la migration des projets existants ont été réalisées dans le respect du planning établi. L'accompagnement des équipes s'est poursuivi pendant quelques temps. A fin juin, près de 400 personnes ont suivi un des 57 tutorats dispensés et près de 80 personnes ont suivi une des onze journées de formation complète. Un an après la mise en place de Squash TM, le retour est positif : en effet, plus de 31 000 exécutions de tests ont été enregistrées dans l'outil depuis juin 2016 et nous avons des demandes de mise en place des dernières nouveautésde Squash TM. Les chiffres parlent d’eux-mêmes. Félicitations aux équipes pour le travail accompli et merci à Odile pour son retour d'expérience. Retrouvez aussi le témoignage de notre client Globaz sur les enjeux de la qualité fonctionnelle au sein de sa structure.

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.

Afin de répondre à une demande émergente, le Centre de Compétences Multi-Technologie d’Informatique Caisse des Dépôts (ICDC) lance en 2009 ses premiers chantiers d’automatisation de test. Maître d’œuvre de référence pour la Caisse des dépôts et l’INPI, ICDC est en charge du patrimoine d’applications de ces deux entités. L’impératif de mettre en service, souvent et rapidement, de nouvelles versions applicatives oblige à placer l’automatisation des tests au centre du dispositif de validation. L’avènement des projets agiles et digitaux en fait un enjeu majeur. Sébastien GONTRAN nous raconte son expérience et les défis relevés. Quels sont pour vous les principaux bénéfices de l’automatisation ? L’automatisation doit permettre d’améliorer la productivité et la qualité du travail des équipes en charge de la réalisation et de la maintenance des applications. Aujourd’hui, l’automatisation des tests est un prérequis, socle de tout développement ou projet d’intégration de progiciels. Quel est le rôle de Henix au sein de cette mission ? Henix est intervenu pour nous proposer son expertise sur la partie outillage avec la mise en place des solutions de Squash TM et de Squash TA. Comment s’est passée la mise en place de l’automatisation ? La première vague de promotion et de diffusion des pratiques d’automatisation a duré environ 4 ans, de 2009 à 2013. Malgré un intérêt fort et partagé pour l’automatisation, nous avons rencontré des difficultés autour de 4 axes suivants : La définition et la collecte des besoins : des difficultés pour recueillir le besoin d’automatisation et définir un périmètre pour les projets d’automatisation.Sur l’axe technique : des méthodes de développements hétérogènes des scripts automatisés et l’absence d’industrialisation dans l’exécution des tests ont conduit à un sentiment de solutions artisanales peu maintenables.Sur l’axe organisationnel, l’absence d’experts internes et le peu d’intérêt pour la montée en compétence sur ce sujet ont conduit à faire intervenir des experts externes avec un turnover qui complexifie à terme la maintenance des tests.Enfin sur l’axe des coûts, prévoir un budget pour l’automatisation restait complexe avec le sentiment pour les projets de réaliser un investissement coûteux au retour aléatoire. L’automatisation au même titre que les tests restait une variable d’ajustement sur les projets. Comment avez-vous fait évoluer votre offre ? "On apprend de ses erreurs" et comme la roue de Deming, le chemin de l’amélioration est sans fin. Les réponses à ces douleurs récurrentes à l’automatisation ont été une réponse à la fois méthodologique et sur l’outillage. Tout d’abord, nous avons capitalisé sur nos années d’expériences en projets d’amélioration autour de Cmmi et appliquer / remis au gout du jour pour les activités d’automatisation : la gestion (recueil et capitalisation) des exigences. Ainsi la collecte des besoins de tests automatisés est désormais systématisée et formalisée à l’aide de fichiers d’échange sous Excel (à l’instar d’une liste des exigences) pour assurer à la fois une traçabilité du besoin, mais aussi pour relever au plus tôt des incohérences dans la formulation des scénarios de tests. Enfin ce fichier de recueil des besoins nous sert à piloter le projet d’automatisation via les besoins, en mesurant à tout moment une couverture des exigences, besoins d’automatisation à implémenter. Sur l’axe technique, nous sommes appuyés sur MAKO : un Framework d’automatisation par mots-clés. Cet outil s’articule avec la démarche des exigences et permet une nouvelle approche de l’automatisation focus sur les besoins. L’outil à partir du fichier Excel en entrée, génère des scripts dans le langage des automates du marché. C’est bien l’outil qui génère en se basant des bonnes pratiques de développement et pas le développeur. Ce dernier intervient à hauteur de 30 % pour des fonctions spécifiques et enrichir l’outil par l’introduction de nouveaux mots clés. En cas de changement ou nouveau besoin, nous repartons du fichier Excel pour regénérer le code, cela évite un retravail fastidieux et facilite la maintenabilité et une meilleure capitalisation. Toujours sur l’axe technique, nous avons mis en place une plateforme de tests automatisés composés d’un ordonnanceur (Jenkins) d’un référentiel de test (Squash TM). Sur l’axe organisationnel, le Framework est venu « changer la donne » du projet d’automatisation. Avant il s’agissait d’un exercice purement technique, requérant la présence d’experts sur toutes les phases de conception et de développement. L’outil permet aux sachant fonctionnels de se réapproprier en grande partie la démarche. Cette approche permet aux sachant fonctionnels de facilement et rapidement « scénariser » leurs cas de test, à l’aide de mots-clés. Un autre accélérateur a été la migration de notre patrimoine de tests de HP QC vers Squash TM. Squash TM permet d’exécuter et de centraliser le reporting des tests automatisés de différentes technologies. Associé à la plateforme d’exécution des tests basée sur Squash TA, il permet de compléter cette réappropriation du test automatisé par les équipes fonctionnelles qui lancent les tests à la demande. Quels ont été les principaux impacts au niveau de la restructuration des équipes suite à ces évolutions ? Un des objectifs était, et est toujours, de permettre une mutualisation des efforts de tests entre les équipes et les couches de tests (fonctionnels, performance, sécurité). L’introduction du fichier d’échange va dans le bon sens car il permet aux équipes fonctionnelles de préciser leur besoin dans un format directement opérationnel. Aujourd’hui, les échanges entre les différentes parties sont donc plus efficaces et l’effort est en partie transféré vers les équipes fonctionnelles qui s’approprient davantage l’automatisation des tests. D’autre part, nous souhaitons impliquer davantage les maîtrises d’œuvre projet pour qu’elles interviennent pleinement dans le processus de maintien du référentiel de tests automatisés, avec également pour objectif d’assurer la réactivité dans la maintenance des tests. Et les impacts au niveau technique ? Aujourd’hui, 70% des étapes de test dans les scripts produits sont directement générées par les mots clés préexistants. Nous estimons un gain de productivité multiplié par 4 grâce à la nouvelle méthodologie. Ce gain est important pour l’insertion de l’automatisation dans les projets agiles qui deviennent un standard. Les cycles de développement sont plus courts et les besoins en tests de non-régression plus importants. Dans un tel contexte, l’automatisation devient une pratique indispensable. Si vous deviez nous indiquer un axe de développement majeur pour la suite, quel serait-il ? Un des objectifs est de continuer le développement de notre méthodologie pour pouvoir formuler les tests avec une syntaxe de type "user-story". Nous souhaitons également étendre notre dictionnaire MAKO pour prendre en charge l’automatisation des applications mobiles qui est une demande émergente. Comme quoi, l’automatisation du patrimoine de tests a de l’avenir ! Merci Sébastien GONTRAN pour ce retour d’expérience enrichissant, et un grand merci pour la confiance accordée à Henix.

Qu’est-ce qu’un jalon ? Quels sont ses objectifs et avantages ? Comment fonctionne-t-il dans Squash ? Dans cet article, nous vous proposons une première initiation aux jalons, en vous présentant leurs grandes caractéristiques et leurs rôles dans la gestion de projet. Objectifs des jalons Les jalons permettent de « versionner » votre référentiel de test et de visualiser uniquement les objets (exigences, cas de test et campagnes) qui leur sont associés. Grâce aux jalons, vous pouvez notamment organiser vos bibliothèques d'objets par version, créer une nouvelle version du référentiel à partir d'une version existante, synchroniser deux versions, et bien plus ! Pour les utilisateurs sous licence, une documentation dédiée incluant plus d’indications sur la prise en main des jalons et leurs différentes fonctionnalités est disponible (Consulter nos offres). Tous les utilisateurs peuvent également retrouver les grandes fonctionnalités des jalons sur notre Wiki. Gestion des jalons Pré-requis : Activer la fonctionnalité. Les fonctionnalités liées au Jalon sont désactivées par défaut. N’oubliez pas d’activer la fonctionnalité depuis l’espace 'Administration'. La gestion des jalons se fait par l’espace ‘Administration’. L’utilisateur doit donc bénéficier d’un profil administrateur ou chef de projet afin d’accéder aux fonctionnalités suivantes : Création, modification et suppression de jalons Affectation de jalons à un ou plusieurs projets Duplication et synchronisation des jalons Quant aux testeurs référents, aux designers de test et testeurs avancés, ils peuvent uniquement associer et désassocier les jalons aux exigences et aux cas de test. L’association aux jalons se fait depuis la bibliothèque via l’onglet 'Jalons' de l’exigence et/ou du cas de test à associer. Mode jalon Pour passer en mode jalon, il faut se rendre dans l’espace dédié : 'Mon compte'. En mode jalon, seuls les objets associés au jalon sont visibles dans la bibliothèque. Une fois en mode jalon, il est également possible de créer une exigence, un cas de test ou une campagne. L’objet créé sera alors directement lié au jalon. Tableau de bord Il est possible de générer des tableaux de bord en mode jalon dans les espaces exigences, cas de test et campagne. Pour chaque espace, tous les objets du référentiel associés au jalon sélectionné sont pris en compte dans les tableaux de bord. Pour cela, en mode jalon, cliquer sur le bouton [Jalon] qui se trouve au-dessus de la bibliothèque. Le tableau de bord prendra en compte l’ensemble des objets du référentiel associés au jalon. Il est également possible de générer les tableaux de bord à partir d’une sélection dans la bibliothèque (projet, dossier, sélection multiple…). Seuls les objets associés au jalon et présents dans la sélection sont pris en compte. Informations complémentaires La portée À chaque jalon est attribuée une portée. La portée est le référentiel de tests qui peut être associé à un jalon. La portée du jalon dépend du statut de l’utilisateur. Lorsqu’un administrateur crée un jalon, celui-ci est par défaut de portée 'Globale' Lorsqu’un chef de projet crée un jalon, ce jalon aura une portée 'Restreinte' (restreint au périmètre des projets pour lesquels le chef de projet a une habilitation de chef de projet). Les statuts des jalons Les différentes fonctionnalités, présentées ci-dessus, sont accessibles non seulement en fonction du statut de l’utilisateur mais également en fonction du statut des jalons. Le tableau ci-dessous reprend les principales fonctionnalités d’un jalon et les statuts sous lequel il doit être pour chaque cas. La duplication et la synchronisation des jalons La duplication et la synchronisation d’un jalon ne sont possibles que si ce dernier est au statut 'En cours' ou 'Terminé'. Duplication : la duplication d’un jalon permet d’associer un nouveau jalon aux projets et/ou aux exigences et/ou aux cas de test d’un jalon source. Synchronisation : la synchronisation permet à un jalon (jalon cible) d’être associé automatiquement à tout ou partie des objets d’un autre jalon (jalon source).

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 version 1.15.0 de Squash TM est disponible en téléchargement. Voici les nouveautés de cette nouvelle version : Tableau de bord dans l'espace 'Exigences' : à la manière de ce qui existe déjà dans les espaces 'Cas de test' et 'Campagnes', il est possible d'afficher un tableau de bord dans l'espace 'Exigences' avec des graphiques sur les exigences orpheline, le statut, la criticité, la présence ou non d'une description, le taux de couverture en fonction de leur criticité et le taux de validation des cas de test associés en fonction de leur criticité. Tableaux de bord personnalisés dans les espaces : possibilité d'afficher un tableau de bord personnalisé (créé dans l'espace pilotage) dans les espaces 'Exigences', 'Cas de test' et 'Campagnes' à la place du tableau de bord par défaut. Refonte de l'assistant dans l'espace 'Pilotage' : les deux premières étapes de l'assistant de création de graphiques personnalisés ont été revues. La 1ère étape concerne uniquement le choix du périmètre du graphique (+ de choix possibles) et la 2ème étape porte sur le choix des entités et des attributs. En fonction du périmètre choisi, les données des graphiques s'adaptent désormais à la sélection lors qu'ils sont déplacés. Prise en compte des champs personnalisés dans l'espace 'Pilotage' : il est maintenant possible de créer des graphiques personnalisés à partir des champs personnalisés. Nouveau champ personnalisé de type numérique : les nombres négatifs et décimaux sont pris en compte. Appel de cas de test par glisser / déposer : possibilité d'effectuer un appel de cas de test par glisser / déposer comme c'est déjà le cas pour l'association exigences - cas de test ou cas de test - campagnes. Plugin AD / LDAP (licence commerciale) : la connexion automatique au bugtracker (si les identifiants sont identiques sur Squash TM et le bugtracker) est désormais possible lorsque les plugins LDAP ou AD sont installés. Et des évolutions d'importance moindre ainsi que nombreuses corrections sur les différents espaces de l'application. Dans cette nouvelle version de Squash TM, la librairie de log a été montée de version de Log4j vers Log4j2. Dans le cas d'une montée de version de Squash TM, il est donc nécessaire de mettre à jour le fichier de configuration des logs ainsi que le script de démarrage de Squash TM. Les procédures sont détaillées dans la section 'Installation guide' du Wiki.

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

La nouvelle version 1.13 de Squash TM est disponible en téléchargement. Cette version apporte de nombreuses évolutions, dont : Espace pilotage : un nouvel espace dédié au reporting a été ajouté. Vous pouvez y créer et stocker des graphiques et tableaux de bord sur mesure (voir illustration ci-dessous). Refonte du moteur de recherche de l’espace campagne : la recherche est désormais plus complète, tant sur les critères que sur les résultats affichés, à l'image de ce qui existe pour les autres espaces. Refonte de l'import/export des exigences : le moteur d'import/export fonctionne désormais à l'identique de celui des cas de test (il permet ainsi des manipulations en masse tel que création et modification... et propose un mode simulation). Modification d'un cas de test pendant l'exécution : vous pouvez désormais autoriser les testeurs à mettre directement à jour le cas de test source pendant une exécution. Taux de couverture des exigences : les taux de couverture, de vérification et de validation d'une exigence sont désormais disponibles dans la page de consultation d'une exigence. Lien 1-n vers les bugtrackers : il est possible dorénavant de lier plusieurs projets d'un bugtracker à un projet Squash, et de choisir au moment de la déclaration le projet cible dans lequelle l’anomalie doit être créée. Et de nombreuses évolutions d'importance moindre sur les différents espaces de l'application (notamment l'espace d'administration). Dans cette nouvelle version de Squash TM, le socle technique a également été refondu. Le serveur applicatif utilisé est désormais Tomcat (au lieu de Jetty jusqu'à la version 1.12). Nous vous invitons à consulter la section "Installation guide" du wiki pour suivre les nouvelles procédures d'installation et de paramétrage.

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.

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) :

L'application Squash TM est livrée sous différents packages : un installeur Windows (.jar) qui permet une installation rapide à des fins de démonstration , un package universel compatible Windows, Mac, Linux (.zip ou .tar.gz), une image Docker En version 1.X de Squash TM un paquet Debian (.deb) et Redhat (.rpm) étaient disponibles mais ces derniers sont aujourd'hui dépréciés. Une procédure indique comment basculer en tarball (tar.gz). Pour plus d'informations sur l'installation de l'applicatif, cliquez ici.

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.