Squash TM supporte Debian 9 (Stretch). Cependant, ce dernier n'accepte plus les clés PGP inférieures à 4096 bits pour les installations via le gestionnaire de paquet ; nous avons donc dû changer la clé permettant d'authentifier les dépôts d'installation, et par conséquent re-signer tous les paquets Debian et Redhat hébergés sur notre dépôt. Cela aura comme conséquence, pour les administrateurs de la solution chez vous, de créer un problème de clé lors de la mise à jour de Squash TM via les commandes "apt" (Debian/Ubuntu) ou "yum install" (RedHat/CentOS), que vous ayez basculé sur Debian 9 ou pas. Voici ce qu'il faut faire pour aller chercher notre nouvelle clé et pouvoir faire les montées de version Squash TM sans message d'erreur : Debian/Ubuntu Télécharger une nouvelle fois la clé et refaire un apt update, soit : wget -q -O - http://repo.squashtest.org/repo.squashtest.org.gpg.key | apt-key add -    apt update RedHat/Centos Passer les commandes ci-dessus. Si cela devait ne pas marcher, faire un clean du package en cache : rpm --import http://repo.squashtest.org/repo.squashtest.org.gpg.key yum install squash-tm En cas d'échec persistant, passer les commandes suivantes : yum clean packages yum install squash-tm

Un plugin connecteur avec le bugtracker Buzilla est disponible pour Squash TM. Pour le télécharger, rendez-vous dans la page Télécharger. Quelques informations pour l'installation : - Téléchargez le .zip ou le .tar.gz et décompressez les fichiers. - Placez le contenu des différents dossiers du plugin dans les dossiers correspondants de votre instance Squash TM. - Après avoir supprimé le dossier felix-cache de votre instance, redémarrez l'application.

Cet article présente l’espace recherche de Squash TM, ainsi que les actions accessibles depuis cet espace. L’outil de recherche est disponible à partir des 3 espaces principaux : l’espace Exigences, Cas de test et Campagnes. 1 – Modification en masse des attributs dans les différents espaces Objectif : sur Squash TM, vous avez toujours la possibilité d’éditer les exigences et les cas de test après leur conception. L’édition peut se faire sur un cas de test ou une exigence en particulier, mais certains attributs peuvent également être modifiés sur plusieurs cas de test ou plusieurs exigences à la fois. Pour illustrer cette fonctionnalité, nous vous donnons ici l’exemple de la modification en masse de certains attributs pour plusieurs cas de test, depuis l’espace Cas de test. Pré-requis : l’utilisateur doit bénéficier des droits d’écriture. La modification de plusieurs cas de test peut se faire sur les attributs suivants : - L’importance - Le statut - Le type - La nature NB : pour les exigences, la modification en masse se fait sur les champs suivants : criticité, catégorie et statut. Pour effectuer les changements voulus, sélectionnez l’assistant de recherche qui se trouve dans la barre d’outils au-dessus de la bibliothèque. Effectuez votre recherche de cas de test en fonction des critères souhaités. Sélectionnez ensuite les cas de test à modifier : Cochez-la ou les cases des attributs à modifier, puis confirmez : L’espace de recherche permet également la modification directe des informations des colonnes Référence, Libellé, Importance, Nature, Type, Statut et Éligibilité à l'automatisation : 2 – Créer une nouvelle itération à partir de l’espace recherche Objectif : la création d’une nouvelle itération à partir de l’espace recherche vous permet un gain de temps considérable sur la gestion de vos projets. Vous repartez de cas de tests existants pour créer une nouvelle itération. Admettons, que, suite à une seconde livraison, vous souhaitez rejouer des tests en échec afin de valider les corrections. Depuis l’outil de recherche dans l’espace Campagnes, sélectionnez dans l’arborescence l’itération contenant les cas de tests à rejouer. Pour information, plusieurs itérations de plusieurs projets différents peuvent être sélectionnées simultanément. Ensuite, vous sélectionnez les cas de tests en échec grâce à l’espace Exécution de la fenêtre qui vous permet de choisir le statut des tests à sélectionner. Il est possible de sélectionner plusieurs attributs. Par exemple, vous pouvez sélectionner les cas de tests en échec mais aussi en succès afin de vérifier la non-régression de certains tests à la suite d’une seconde livraison. Sur cette fenêtre, il est possible d’appliquer d’autres filtres pour sélectionner les cas de test en fonction du mode d’exécution, du jalon et des attributs attitrés aux cas de test. Vous pouvez également renseigner directement l’ID du cas de test dans la barre de texte du volet informations. Une fois les caractéristiques des tests sélectionnées, cliquer sur [Lancer la recherche]. Les tests correspondants apparaissent. Sélectionner les cas de test souhaités, puis cliquer sur le bouton [Ajouter]. Une fenêtre pop-up s’ouvre. Vous devez maintenant sélectionner dans quelle itération vous souhaiter intégrer les cas de tests. Deux manières de faire : En ajoutant les cas de test sélectionnés dans une itération existante. En créant une nouvelle itération avec les cas de test sélectionnés. Ici, nous créons une nouvelle itération. Attention à bien cliquer sur [Ajouter] pour intégrer les tests choisis dans la nouvelle itération. Depuis l’espace Recherche des campagnes, vous pouvez également modifier en masse le statut des cas de tests. Procédez de la même manière que dans l’espace Recherche des cas de tests : sélectionnez les tests à modifier, cliquez sur [Modifier] et sélectionnez le statut choisi. Une nouvelle itération a bien été créée dans la bibliothèque de l’espace Campagnes. Le tutoriel sur l'espace recherche est également en vidéo sur notre chaîne Youtube.

La version 1.17.0 de Squash TM est disponible en téléchargement. Voici les nouveautés de cette version : Amélioration des performances : l'affichage des différents espaces ainsi que des pages de recherche est maintenant plus rapide, avec un facteur 10 sur les bases de données volumineuses Visibilité sur les exigences lors de la saisie des pas de test : lors de la saisie de pas de test, il est désormais possible de visualiser sur le même écran les attributs des exigences associées au cas de test Utilisation des paramètres dans les prérequis des cas de test : les paramètres et jeux de données sont pris en compte dans le champ 'Prérequis' des cas de test Ajout d'un état fonctionnel aux campagnes et itérations : permet de définir manuellement un état pour les campagnes et itération (Planifié, Terminé, Archivé...) Ajout d'un statut d'exécution aux suites de test : un statut d'exécution est automatiquement déterminé pour les suites de tests sur la base du statut d'exécution des tests qui les composent Modification du statut d'exécution d'un pas de test depuis la page de consultation des exécutions : il est désormais possible de modifier le statut d'exécution des pas de test par une sélection dans une liste déroulante depuis le bloc 'Scénario' d'une exécution Fusion des espaces rapport et pilotage : les rapports sont maintenant accessibles depuis l'espace Pilotage via le bouton [Créer]. Ils apparaissent alors dans la bibliothèque et peuvent être modifiés ou téléchargés ultérieurement Taille de la base de données dans les statistiques : la taille de la base de données figure dans les statistiques de la page d'administration Reporter les associations exigences - cas de test lors de la création d'une nouvelle version de l'exigence Plugin Assistant de campagne (Licence Pro) : dans cette première version, ce plugin présente une fonctionnalité de reprise d'itération qui permet de créer une nouvelle itération à partir d'une itération existante sur la base de différents critères simples (tests en échec, tests liés à des anomalies, etc...) ou avancés (attributs des exigences liées, suites de tests, etc...) Plugin Tuleap (Licence Pro) : connecteur au bugtracker Tuleap Plugin Redmine Exigences (Licence Premium) : connecteur permettant de synchroniser les exigences présentes dans Redmine vers l'espace exigences de Squash TM Et des évolutions d'importance moindre ainsi que nombreuses corrections sur les différents espaces de l'application.

Derrière le développement de Squash TM, on retrouve une équipe constituée de membres issus de différents domaines d’expertise. Aujourd’hui Benoît, membre de l’équipe Squash depuis 2010 et principal développeur du plugin Squash4Jenkins, nous raconte son parcours, l’organisation de Squash et des technologies sous-jacentes au développement de l’outil de gestion de patrimoine de test. Bonjour Benoît. Pour commencer, peut-être peux-tu nous en dire un peu plus sur ta formation ? Après un Master Recherche en informatique orienté Intelligence Artificielle, j’ai suivi quelques stages en robotique et en navigation autonome avant d’effectuer une thèse à Orsay, et devenir docteur de l’INRIA Saclay en neurosciences computationnelles. Ce fut une période très enrichissante mais je ne souhaitais pas poursuivre plus loin. Je décidai alors de me reconvertir vers une filière plus portée vers l’ingénierie. Comment as-tu mené cette reconversion ? Je me suis lancé dans la recherche de formations en ingénierie. J’ai pris connaissance de différents sites proposant des formations et suis tombé sur la formation de 6 mois dispensée par l’AFCEPF. Le cursus proposé répondait à mes attentes et bénéficiait d’une bonne réputation. C’est par le biais de l’AFCEPF que j’ai ensuite été mis en contact avec Henix, pour finalement intégrer la société en novembre 2010. Quelles sont tes premières missions dans la société ? 2010 est une période clé pour Henix, qui est en plein développement de sa nouvelle activité d’éditeur de logiciel. Squash TM, l’outil pour la gestion de patrimoine de tests n’est alors qu’un « mini-POC ». J’ai intégré l’équipe Squash, et les 5 premières années ont été exclusivement dédiées à la conception et au développement de Squash TM. Après quoi, d’autres tâches sont venues compléter le travail d’un développeur de l’équipe Squash et constituent aujourd’hui « mon quotidien ». Peux-tu nous en dire un peu plus sur ces différentes missions qui te sont aujourd’hui assignées ? Parmi les tâches qui me sont confiées, je ne travaille plus uniquement à la conception / au développement. Je suis également mobilisé en tant que : Consultant technique : pour des missions d’audit ou d’expertise répondant à des sollicitations des clients Expert sur de la formation : pour aider les clients à développer leurs propres extensions pour Squash. Actuellement, comment se compose l’équipe Squash ? L’équipe de développement de Squash se constitue d’un Scrum Master, un Product Owner, 8 développeurs et un chargé de recette. Mais l’équipe Squash, ce n’est pas uniquement l’équipe de développement : nous sommes également appuyés par une équipe support, une entité Professional Services et une équipe dédiée au Marketing. Et pour les développeurs, comment s’organise une journée type ? Il y a 3 tâches principales qui nous occupent au quotidien : Le développement Une nouvelle version de Squash TM est publiée de façon biannuelle. Nous travaillons quotidiennement sur les nouvelles fonctionnalités prévues sur la roadmap pour assurer l’amélioration de l’outil. Le support Un développeur peut être mobilisé de façon ponctuelle pour répondre aux demandes clients. Les actions support sont toujours prioritaires aux autres tâches. Le Code review Le vendredi est consacré à l’audit du code de Squash par les pairs. Comment s’organise l’équipe sur la partie développement ? En temps normal, un développeur travaillera sur une nouvelle fonctionnalité. Evidemment, l’organisation dépend aussi de la charge de travail prévisionnelle pour le développement de la fonctionnalité. Dans l’équipe, nous fonctionnons en mode agile : Retours fréquents entre la MOE et MOA, stand-up meetings pour faire le point sur l’avancée de chacun. Nous planifions nos tâches par sprint lorsque nous travaillons sur les nouvelles fonctionnalités, avec une livraison et des restitutions à la fin de chaque sprint. Chaque développeur de l’équipe Squash est full stack : chacun est capable d’intervenir à n’importe quel niveau de l’application. Peux-tu nous dire quelques mots sur les technologies sous-jacentes et les environnements de développement utilisés ? Pour Squash, nous travaillons sur IntelliJ, un IDE Java. Sur les technologies utilisées, les principales à retenir sur la partie serveur sont Hibernate (un ORM), Spring (pour la couche web et intégration), JSP et Thymeleaf (pour la génération du HTML). Le client est bâti sur JQuery et Backbone. Nous hébergeons les sources sur Bitbucket, et versionnées avec Mercurial. Comme plateforme d’intégration continue, nous utilisons Jenkins. SonarQube pour la qualimétrie et Maven comme technologie de build. Un mot sur le prochain challenge de l’équipe ? En ce moment, nous étudions le renforcement de l’intégration entre Squash et Jira pour une meilleure coordination entre les équipes de développement et de qualification dans le cadre des projets agiles au sein des cellules de tests. Vous en découvrirez un peu plus dans la versoin 1.17 de Squash. Merci à Benoît pour son retour d’expérience, nous attendons donc plus de précisions sur Roadmap de la version 1.17 de Squash TM.

Le plugin Squash4Jenkins est disponible sur la marketplace Jenkins. Il s'agit d'un plugin Jenkins qui ne nécessite donc aucune installation côté Squash TM. Ce plugin publie les résultats des tests des builds Jenkins dans Squash TM. Il fonctionne en complément d'autres plugins de publication associés aux technologies des tests du build (JUnit, NUnit, MSTest, etc.). Le plugin permet à Squash TM de recenser les différents tests d’un job, de déclencher le build et de regrouper les résultats des tests. Grâce à ce plugin, il est possible de récupérer les résultats uniquement si les builds sont déclenchés par Squash TM. Le plugin Squash4Jenkins est open source et est diffusé sous la licence MIT des plugins Jenkins pour mieux s'intégrer à l'écosystème Jenkins. Pour plus d'informations, vous pouvez consulter la documentation en ligne où figurent notamment les guides de configuration et d'utilisation.

Par défaut, Squash TM utilise le port 8080. Ce port peut être modifié, la procédure est variable selon le système d’exploitation. Dans tous les cas, rechercher HTTP_PORT et remplacer le port 8080 par celui souhaité. Windows : Dans le fichier bin/startup.bat : set HTTP_PORT=8080 Linux : Dans le fichier bin/startup.sh : HTTP_PORT=8080 Debian/Ubuntu : Dans le fichier ect/init.d/squash-tm : HTTP_PORT=8080 RedHat : Dans le fichier ect/sysconfig/squash-tm : HTTP_PORT=8080 Notez cependant que le système ne vérifiera pas si le port choisi est disponible (à moins que vous n'utilisiez le script de lancement Debian), assurez-vous donc auprès de l'administrateur que c'est bien le cas.

La configuration des pièces jointes se fait directement dans l’application. Pour cela, il faut se connecter en tant qu’administrateur à Squash TM et aller dans Administration puis Paramètres système. Dans le bloc Pièces jointes : 1. Dans la liste blanche pour l’upload de fichier, renseigner les extensions à autoriser, séparées par des virgules. Par défaut, les extensions suivantes sont indiquées : txt, doc, xls, ppt, docx, xlsx, pptx, odt, ods, odp, pdf, xml, png, jpg. 2. Dans la taille limite d’upload en bytes, renseigner la taille maximum autorisée (par défaut 4 000 000). 3. Dans la taille limite d’upload de fichier d’import en bytes, renseigner la taille maximum autorisée (par défaut 2 000 000) Si vous utilisez une base de données de type MySQL, pensez également à compléter la propriété max_allowed_packet=X (où X est la taille max des pièces jointes admissibles par Squash. Par défaut, l'application est paramétrée pour 2Mo, soit X=2M) dans le fichier de configuration de MySQL (my.cnf ou my.ini).

Squash TM est pourvu d'un système d'import / export des Exigences et des Cas de Test, permettant d'alimenter la base de données Squash, ou d'en extraire des informations, en s'appuyant sur des fichiers Excel. On y accède par les boutons au-dessus de l'arbre des Exigences ou des Cas de Test : Le fichier généré lors de l'export est un fichier XLS. Les formats supportés pour l'import sont XLS, XLSX et XLSM. Un template des fichiers d'import est disponible depuis la popup d'import : L'import permet aussi bien la création de nouvelles Exigences / nouveaux Cas de Test, que la mise à jour d'éléments existants. Les formats d'import / export sont quasi identiques, ce qui permet la mise à jour en masse d'une liste d'éléments que vous aurez sélectionnés dans l'arbre. Pour exporter puis importer un fichier d'exigences ou de cas de test que vous aurez entre temps modifié, suivez ces différentes étapes : Export d'exigences / cas de test 1. Allez dans l'espace Exigences / cas de test 2. Sélectionnez les éléments à exporter 3. Cliquez sur le bouton [Importer/Exporter...] du menu de l'arbre : 4. Cliquez sur l'action "exporter" dans le menu déroulant 5. Une pop up "Exporter" s'ouvre. Cliquez sur le bouton [Exporter] et sauvegardez le fichier Modification du fichier exporté 1. Ouvrez le fichier Excel d'export 2. Ajoutez une colonne ACTION au début des feuilles des onglets suivants dans les fichiers d'export : Pour l'export d'exigences : dans l'onglet 'REQUIREMENT' Pour l'export de cas de test : dans l'onglet 'TEST_CASES', 'STEPS', 'PARAMETERS', 'DATASETS' 3. Pour chaque ligne de cette colonne, ajoutez les valeurs suivantes : C ou CREATE : si le but est de créer de nouveaux éléments U ou UPDATE : si le but est de modifier des éléments existant 4. Sauvegardez le fichier Import du fichier 1. Allez dans l'espace exigence / cas de test : 2. Cliquez sur le bouton [Importer/Exporter...] du menu de l'arbre : 3. Cliquez sur l'action "importer" dans le menu déroulant. Une pop up "Importer au format Excel" s'ouvre. 4. Cliquez sur [Parcourir] puis sélectionnez le fichier modifié précédemment 5. Cliquez sur le bouton [Importer]

Squash TM est nativement lié au bugtracker Mantis mais dispose également de plugins connecteurs avec les bugtrackers Jira, Bugzilla, Redmine et RTC. Pour paramétrer un bugtracker, il faut suivre ces quelques étapes : 1. Ajouter un bugtracker Pré-requis : Avoir correctement installé le plugin correspondant 1. Depuis la page d’accueil de l’administration, cliquer sur le bouton [Bugtrackers]. 2. Cliquer sur le bouton [Ajouter un bugtracker]. Une fenêtre pop-up s’ouvre : 3. Renseigner les informations demandées : NomType : Liste déroulante proposant les bugtrackers correspondants aux plugins installés URL : URL du bugtracker. ex : http://localhost/mantis S’affiche dans l’Iframe : si la case est cochée, en cliquant sur le bouton de l’Espace Bugtrackers dans la barre de navigation, le bugtracker s’affichera dans la zone de travail. Si la case n’est pas cochée, il s’ouvrira dans une nouvelle fenêtre. Attention : certains bugtrackers ne supportent pas cette fonctionnalité. 4. Cliquer sur le bouton [Ajouter]. Le tableau de l'Espace Bugtrackers est mis à jour. 2. Lier un bugtracker à un projet Squash TM 1. Depuis la page d’accueil de l’administration, cliquer sur le bouton [Projets] 2. Ajouter un projet ou cliquer sur le nom d’un projet existant 3. Dans le bloc Bugtracker, renseigner les informations suivantes : Champ ‘Bugtracker’ : sélectionner le bugtracker ajouté à la première étape Champ ‘Nom du projet dans le bugtracker’ : saisir le nom du projet dans le bugtracker en respectant la casse. Un projet Squash TM peut être lié à plusieurs projets du bugtracker. Plusieurs projets Squash TM peuvent être liés au même projet du bugtracker.

La version 1.16.0 de Squash TM est disponible en téléchargement. Voici les nouveautés de cette version : Liens entre versions d'exigences : il est maintenant possible de lier des versions d'exigences entre elles et de typer ce lien. Le nouveau bloc 'Exigences liées' présent sur la page de consultation des exigences permet d'effectuer les associations et de voir les versions d'exigences liées à l'exigence consultée. Les types de lien entre versions d'exigences sont personnalisables via un nouveau menu présent dans l'administration. Date de dernière connexion des utilisateurs : la date et l'heure de dernière connexion des utilisateurs à Squash TM est désormais visible dans le tableau des utilisateurs ainsi que sur la page de consultation de chaque utilisateur. Suites de tests dans le rapport 'Avancement de l'exécution' : une nouvelle colonne 'Suites de tests' a été ajoutée dans l'onglet 'Liste des cas de test par campagne' du rapport 'Avancement de l'exécution'. Anomalies dans les rapports 'Bilan de campagne' et 'Bilan d'itération' (Licence Premium) : des informations relatives aux anomalies sont maintenant présentes dans ces rapports lorsque le bugtracker associé au projet est Jira ou Redmine. Une première partie présente le nombre d'anomalies par criticité et par statut selon leur type et une deuxième partie donne la liste des anomalies (à la manière de ce qui existe dans l'onglet 'Anomalies connues'). Plugin AD / LDAP (Licence Premium) : la connexion multi-domaines est désormais prise en compte. Et des évolutions d'importance moindre ainsi que nombreuses corrections sur les différents espaces de l'application.

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 :