C’est officiel depuis le 03 février 2022, Squash fait partie de la liste des Alliance Partners de GitLab. Ce partenariat marque le fait que les équipes de développement de Squash travaillent désormais avec celles de GitLab afin de proposer la meilleure intégration possible entre leurs deux outils. Cette intégration pourra donc permettre plusieurs interactions résumées par des flèches dans ce schéma et détaillées plus loin dans cet article : Pourquoi GitLab ? L'offre intégrée de GitLab permet de remplacer totalement ou en partie la multiplicité des outils DevOps utilisés aujourd'hui (par exemple Bitbucket pour stocker les dépôts Git, Jenkins pour la forge CI/CD, Jira pour la gestion des exigences et le bug tracking, Nexus comme repository manager, Sonar pour l'analyse statique de code…), simplifiant ainsi leur environnement de développement. Squash TM reste l’outil de gestion du patrimoine de test. Les utilisateurs de Squash TM qui souhaiteraient utiliser GitLab n'auront donc aucune perte de fonctionnalités par rapport à leurs workflows actuels. Pour aller plus loin, retrouvez ci-dessous la liste des intégrations (sorties et prévues) entre Squash et GitLab pour l’année 2022 : Intégration de Squash DEVOPS avec GitLab Aujourd’hui, Squash DEVOPS permet d'intégrer dans vos pipelines CI/CD GitLab l'exécution d'un plan de test automatisé défini dans Squash TM et d'y remonter les résultats des tests, leurs attachements ainsi qu'un rapport Allure donnant une vue d'ensemble de l'exécution du plan. Fin mars 2022, la prochaine version de Squash DEVOPS permettra d'arrêter le pipeline en cas d'échec d'un test. Mi-2022, les critères d'arrêt du pipeline pourront être raffinés pour autoriser un seuil d'échecs pour certains types de test (par exemple 10% de tests "flaky"* sur l'interface utilisateur). Mi-2022, Squash DEVOPS apportera également une première version d'export des résultats de tests vers un outil de BI. * Un test est "flaky" lorsqu’il peut à la fois être en succès ou en échec sur le même code. Intégration de Squash TM avec GitLab en tant que bugtracker : Depuis décembre 2021, cette intégration permet de déclarer une anomalie préremplie avec les données du test depuis Squash TM dans GitLab, de rattacher une anomalie déjà présente dans GitLab à Squash TM et de suivre l’avancement de la résolution des anomalies via des tableaux récapitulatifs dans Squash TM. Intégration de Squash TM avec GitLab en contexte agile Prévue pour mi-2022, cette intégration permettra de synchroniser des issues GitLab en exigences Squash TM afin de concevoir, lier et planifier les tests qui les vérifient. Dans GitLab, un suivi en temps réel des activités de test sera disponible. L’ensemble des composants et fonctionnalités cités ci-dessus sont ou seront disponibles gratuitement.

Vidéo en anglais sous-titrée en français

A l'occasion de la sortie de la prochaine de la version 4.0.0 de Squash TM, prévue fin S1 2022, la version de Java et les drivers de connexion aux bases de données PostgreSQL et MariaDB sont mis à jour. En conséquence de choix imposés par ces outils, Squash TM 4.0.0 ne sera pas compatible avec : MySQL quelle que soit sa version MariaDB 10.1 PostgreSQL 9 (pour rappel PostgreSQL 10 n'est également pas supporté) Java 8 (Java installé sur la machine hébergeant Squash TM) Si vous utilisez Squash avec une de ces versions, nous vous recommandons de réaliser la montée de version de vos outils ou de réaliser une migration dans le cas de MySQL avant d'envisager un upgrade en version 4.0 de Squash TM. Si vous êtes dans ce cas, voici nos recommandations par outils : MySQL : Pour remplacer votre MySQL, vous devrez réaliser une migration de votre base de données Squash TM vers MariaDB ou PostgreSQL. La migration MySQL vers MariaDB se fait naturellement grâce à la proximité des deux outils. Pour vous guider dans cette démarche, vous pouvez vous appuyer sur la documentation MariaDB à ce sujet : https://mariadb.com/kb/en/upgrading-from-mysql-to-mariadb/ . Nous recommandons la version 10.5 de MariaDB. La migration MySQL vers PostgreSQL est possible mais plus complexe. Si celle-ci vous intéresse, Henix peut proposer une prestation pour cette migration. Merci dans ce cas de prendre contact via ce lien : https://www.henix.com/rdv-avec-un-ingenieur-produit-squash-gitlab . PostgreSQL : Pour réaliser l'upgrade de votre PostgreSQL suivre les recommandations de la documentation PostgreSQL : https://www.postgresql.org/docs . Nous recommandons un upgrade à minima version 11 de PostgreSQL ou supérieure car les versions 9 et 10 ne sont pas supportées. Java : Nous recommandons la version 11 de Java pour installer la prochaine version de Squash TM. L'outil est également compatible avec OpenJDK.

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 version 1.21 de Squash a été publiée à la fin du mois de décembre, découvrez en images les nouveautés qu'elle vous apporte : ✓ Configuration de l’URL publique de Squash La configuration de la "callbackurl" de Squash se fait depuis l'administration. ✓ Mise à jour de la date de modification pour... ... les exigences, les cas de test, les campagnes, les itérations et les suites de tests si leur contenu est modifié par un utilisateur. Le champ « Modifié le... » des cas de test est mis à jour lorsqu’une modification des pas de test est réalisée. ✓ Ajout du champ "Statut d'avancement"... ...dans le bloc "Description" d'une itération ✓ Ajout d'un bloc "Statistiques" dans l'onglet "Informations" d'une itération : Ce tableau permet de suivre l'avancement de l'exécution des cas de test présents dans l'itération. ✓ Export de campagne personnalisé - périmètre étendu aux itérations et suites : Il est possible de créer un export personnalisé en ciblant une itération ou une suite de tests. ✓ Export de campagne personnalisé - exporter l'ID de l'exécution et les champs personnalisés des pas de test : Les options permettant d'exporter l'ID d'une exécution et les champs personnalisés liés aux pas de test sont maintenant disponibles. API Rest : ✓ Fixation de l'ordre des ITPI : Les items de plan de test des campagnes, itérations et suites de tests sont récupérés dans l'ordre affiché dans Squash. ✓ Gestion des groupes de permissions sur un projet depuis l'API : Modification et suppression d'habilitations possibles depuis l'API. GIT Connector : ✓ Configuration de l'adresse mail du commiter Squash TM... ...lors de la transmission dans Git. Active Directory : ✓ Configuration d'un compte de service pour parcourir Active Directory Jira Bugtracker : ✓ Renseignement automatique du champ ‘Rapporteur’ : Le champ rapporteur est renseigné automatiquement avec le login de l'utilisateur connecté. ✓ Laisser les champs vides ou les valoriser par "Aucun" par défaut : Lors de la déclaration d'anomalies depuis Squash dans Jira, les champs obligatoires et facultatifs sont par défaut laissés vides ou valorisés par "Aucun". Xsquash4Jira : ✓ Désactivation/Activation globalement ou individuellement des synchronisations : Le bouton de désactivation d'une synchronisation interrompt les mises à jour d'exigences et de champs de reporting sans la supprimer. Elle peut être réactivée à tout moment. ✓ Lien vers les pièces jointes Jira dans les exigences synchronisées : Des liens vers la/les pièces jointes du ticket synchronisé sont présents et cliquables à la fin de la description de l'exigence. Xsquash : ✓ Configuration de Xsquash par projet Jira : Pour chaque projet Jira, il est possible d'activer/désactiver le plugin Xsquash et de configurer l'instance Squash avec laquelle le projet Jira doit être synchronisé. ✓ Paramétrage des onglets dans Jira : Il est possible de renommer le nom des onglets "Cas de test Squash TM" et "Exécutions Squash TM". ✓ Onglet "Cas de test Squash TM" avec le statut de la dernière exécution : Une pastille colorée indique le dernier statut d'exécution du cas de test. ✓ Onglet "Exécutions Squash TM " avec les commentaires des pas d'exécution : Les commentaires ajoutés lors de l'exécution des pas de test sont récupérés. Workflow Automatisation Jira : ✓ Externaliser le workflow d’automatisation des tests dans Jira : Il est désormais possible de transmettre un cas de test à automatiser depuis Squash vers Jira. Parallèlement, s’il s’agit d’un cas de test Gherkin, celui-ci est transmis dans GitHub. Ce cas de test apparaîtra sous la forme d’un ticket Jira. Les champs relatifs au cas de test seront synchronisés directement depuis Squash dans ce ticket et le statut d’avancement du ticket sera synchronisé depuis Jira dans Squash. A partir du workflow du ticket Jira, l’automaticien pourra renseigner l’avancement de son travail d’automatisation. Le testeur fonctionnel pourra, de son côté, suivre l’évolution du travail de l’automaticien directement sur Squash. Une fois le cas de test automatisé, l’information est remontée de Jira vers Squash et le cas de test peut ensuite être exécuté en cliquant sur le bouton « Lancer les tests automatisés » dans l’Espace Campagnes de Squash. Télécharger Squash TM 1.21

La version 1.20 de Squash TM a été publiée au début du mois de juillet, découvrez en images les nouveautés qu'elle vous apporte : ​ ✓ Refonte du moteur de recherche : amélioration de la fiabilité et du temps de réponse de la recherche ✓ Pilotage : nouvel assistant pour l'export de campagnes personnalisable : Cet élément de reporting permet de générer un export de campagne à l’aide d’un tout nouvel assistant qui permet de choisir le périmètre et les données à exporter. Les exports personnalisés sont à télécharger au format .csv. ✓ Cahier de test : nouvelles options pour l'impression d'éléments personnalisés Il est désormais possible d'imprimer les pas de test, les pas de test des cas de test appelés, les paramètres et les jeux de données, les exigences liées aux pas de test ou le nombre de pièces jointes des pas de test au sein des cahiers de test. ✓ Cahier des exigences : nouvelle option pour imprimer uniquement la dernière version d'une exigence Il est désormais possible de filtrer et d'imprimer uniquement la dernière version d'une exigence sans l'historique de ses précédentes versions. ✓ Campagnes : possibilité de lancer l'exécution de tests à la chaîne au sein d'une itération Lorsque vous cliquez sur [Lancer], il est désormais possible d'exécuter à la chaîne les tests présents dans l’itération soit ‘avec l’IEO’ soit ‘avec la pop-up’. ✓ Base de données : non duplication des pièces jointes en base de données lors de la duplication d'éléments comprenant des pièces jointes. Une optimisation qui va éviter de surcharger votre base de données d'éléments identiques si vous copier/coller une exigence, un cas de test ou une exécution qui inclut des pièces jointes. ✓ Optimisation des performances : diminution du temps de génération des rapports ✓ Connecteur : enregistrement des identifiants de connexion aux bugtrackers pour chaque utilisateur Il est désormais possible de configurer sa connexion à un bugtracker automatiquement sans avoir à rentrer systématiquement ses identifiants. ✓ Enrichissement de l'API : doc accessible ici ✓ Lien TM-TF : transmission directe des jeux de données lors de l'exécution d'un test automatisé Lors de l’exécution d’un cas de test automatisé, les informations du jeu de données sélectionné pour l’exécution du test dans l’espace Campagnes sont transmises directement à Squash TF sous la forme d’un fichier JSON. ✓ Lien TM-TF : fichiers .feature dans GIT organisés à l'image des tests dans l'arborescence Squash TM Les fichiers GIT sont désormais systématiquement organisés en dossiers / sous dossiers comme c'est le cas dans l'arborescence de Squash. ✓ Compatibilité : Squash est désormais compatible avec Jira 8 et Redmine 4 ​ ​ A noter pour finir que la version 1.20 de Squash TM est compatible avec les versions 5.7. 17 et + de MySQL mais ne supporte pas la version 8.0 et toutes les versions supérieures. Télécharger Squash TM 1.20

Le 6 juin, le Club Utilisateurs Squash a permis de mettre en avant la nouvelle release des composants de Squash TF qui inclut notamment un nouveau connecteur Junit dans le Squash Keyword Framework, un nouveau rapport dédié aux exécutions Cucumber ou encore un plugin IntelliJ IDEA pour faciliter l'écriture des tests automatisés (téléchargements : ici, roadmap : ici). ​ Comme une bonne nouvelle n'arrive jamais seule, un calendrier de formations Squash TF a également été mis en ligne sur le site d'Henix. Composées de trois modules complémentaires (TF-1, TF-2, TF-3), elles vous permettront de prendre en main cette solution d'implémentation et d’exécution de tests automatisés. Retrouvez leurs objectifs respectifs ci-dessous : ​ Module TF-1 : Automatisation avec le Squash Keyword Framework (pour les testeurs automaticiens) ✓ Maîtriser les mots clés du Squash Keyword Framework (SKF) et leur intégration dans la suite Squash TF ✓ Savoir utiliser SoapUI Open Source pour automatiser les tests de services Web ✓ Savoir automatiser des tests d’IHM web avec Selenium / Junit ✓ Savoir utiliser Appium pour l’automatisation d’applications mobiles Module TF-2 : Automatisation code natif en BDD (pour les développeurs automaticiens) ✓ Savoir mettre en place un worklow d’automatisation en contexte Behaviour Driven Development dans l’écosystème Squash ✓ Savoir utiliser SoapUI Open Source pour automatiser les tests de services Web ✓ Savoir automatiser des tests d’IHM web avec Selenium / Junit ✓ Savoir utiliser Appium pour l’automatisation d’applications mobiles Module TF-3 : Exécution et orchestration des tests (pour les testeurs et développeurs automaticiens) ✓ Maîtriser l’industrialisation de l’exécution des tests avec le serveur d’exécution de Squash TF ✓ Savoir mettre en place une configuration multi-environnement pour répondre à des besoins spécifiques ✓ Savoir configurer le lien entre Squash TM et Squash TF pour exécuter et informer du statut d’exécution des tests sur Squash TM ✓ Lire et interpréter le reporting de Squash TF Découvrir le calendrier des formations

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.

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.

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

Principes généraux : L'import d'exigences se fait à partir de fichier Excel (formats .xls, .xlsx ou .xlsm). Ce fichier doit avoir un format spécifique, le gabarit d'import peut être téléchargé dans l'application ou ici. Il permet d'importer à la fois des exigences, des associations exigences / cas de test et des liens exigences / exigences. Pour importer un fichier d'exigence : 1. Allez dans l'espace Exigences 2.Cliquez sur le bouton [Importer] du menu de l'arbre 3. Cliquez sur l'action "importer" dans le menu déroulant : 4. Une fenêtre pop-up "Importer au format Excel" s'ouvre dans laquelle vous pouvez : Télécharger le gabarit d'import Choisir le fichier Excel à importer en cliquant sur "parcourir" Importer le fichier ou simuler un import du fichier 5. Après avoir cliqué sur [Importer] ou [Simuler] puis confirmé, une fenêtre récapitulant l'import apparaît. Le récapitulatif de l'import des exigences est présent au niveau de la ligne "Exigence", celui des associations exigences / cas de test au niveau de la ligne "Association" et celui des liens exigences / exigences au niveau de la ligne "Liens". Il est possible de télécharger un bilan d'import avec le détail des lignes traitées en succès, avec réserve ou en échec : 6. Si l'option "Importer" a été choisie, les exigences, les associations exigences / cas de test et les liens exigences / exigences apparaissent dans l'arborescence de l'espace Exigences. Règles à respecter pour construire le fichier Excel : - Le fichier Excel importé doit contenir un tableau comprenant les colonnes décrites ci-après dans le tableau. - Les données importées sont matérialisées par un couple balise/valeur(s). - Les balises sont toujours placées en première ligne (entêtes du tableau), dans n'importe quel ordre. - La(les) valeur(s) est(sont) placée(s) dans la(les) ligne(s) en-dessous(suivent) de la première ligne des balises. - L'import se fait ligne par ligne. L'ordre des lignes n'a pas d'importance. - Les noms de champs de la première colonne ne sont pas sensibles à leur inscription en majuscule ou en minuscule. - Les lignes vides ne sont pas interprétées. - Les cellules ne doivent pas être fusionnées. Description de l'onglet 'REQUIREMENT' du fichier d'import : ACTION (Obligatoire pour la création d'exigences) > Détermine l'action à effectuer. Doit comporter les valeurs (ou lettres) suivantes : >> CREATE (C) : lors de la création d'une exigence >> UPDATE (U) : lors de la mise à jour d'une exigence PROJECT_ID > ID du projet de destination PROJECT_NAME > Nom du projet de destination REQ_PATH (Obligatoire) > Chemin de l'exigence du nom du projet jusqu'au nom de l'exigence ex : /Nom du projet/Nom du dossier/Nom de l'exigence REQ_VERSION_NUM > Numéro de la version de l'exigence REQ_VERSION_REFERENCE > Référence de la version de l'exigence REQUIREMENT_VERSION_NAME > Nom de la version d'exigence REQ_VERSION_CRITICALITY Code de la criticité de la version de l'exigence : CRITICAL, MAJOR, MINOR, UNDEFINED REQ_VERSION_CATEGORY > Code de la catégorie de la version de l'exigence (liste par défaut) : CAT_FUNCTIONAL, CAT_NON_FUNCTIONAL, CAT_USE_CASE, CAT_BUSINESS, CAT_TEST_REQUIREMENT, CAT_UNDEFINED, CAT_ERGONOMIC, CAT_PERFORMANCE, CAT_TECHNICAL, CAT_USER_STORY, CAT_SECURITY REQ_VERSION_STATUS > Code du statut de la version l'exigence : APPROVED, OBSOLETE, UNDER_REVIEW, WORK_IN_PROGRESS REQ_VERSION_DESCRIPTION > Description de la version de l'exigence REQ_VERSION_CREATED_ON > Date de création de la version de l'exigence REQ_VERSION_CREATED_BY > Login du créateur REQ_VERSION_LAST_MODIFIED_ON > Date de modification de la version de l'exigence REQ_VERSION_LAST_MODIFIED_BY > Login du dernier modificateur REQ_VERSION_MILESTONE > Jalon(s) associé(s) à la version de l'exigence REQ_VERSION_CUF_ > Code des champs personnalisés associés à la version de l'exigence Description de l'onglet 'LINK_REQ_TC' du fichier d'import : REQ_PATH > Chemin de l'exigence depuis le nom du projet jusqu'au nom de l'exigence ex : /Nom du projet/Nom du dossier/Nom de l'exigence REQ_VERSION_NUM > Numéro de la version de l'exigence à lier TC_PATH > Chemin du cas de test depuis le nom du projet jusqu'au nom de l'exigence ex : /Nom du projet/Nom du dossier/Nom de l'exigence Description de l'onglet 'LINK_REQ_REQ' du fichier d'import : ACTION > Détermine l'action à effectuer. Doit comporter les valeurs (ou lettres) suivantes : >> CREATE (C) / UPDATE (U) : lors de la création ou la mise à jour d'un lien entre versions d'exigences >> DELETE (D) : lors de la suppression d'un lien entre versions d'exigences REQ_PATH > Chemin de l'exigence depuis le nom du projet jusqu'au nom de l'exigence REQ_VERSION_NUM > Numéro de la version de l'exigence RELATED_REQ_PATH > Chemin de l'exigence liée depuis le nom du projet jusqu'au nom de l'exigence RELATED_REQ_VERSION_NUM > Numéro de la version de l'exigence liée RELATED_REQ_ROLE > Code du rôle de l'exigence liée Pour plus d'informations sur l'import d'exigences, vous pouvez consulter la page dédiée sur notre Wiki.