190 résultats trouvés avec une recherche vide
- Squash sur le devant de la scène
L'équipe Squash est actuellement à Bordeaux pour la 7ème édition du UCAAT (User Conference on Advanced Automated Testing). En effet, du 22 au 24 octobre, c'est au Palais de la Bourse de Bordeaux qu'a lieu ce salon international dédié à toutes les tendances du test automatisé. Organisé chaque année dans une ville d'Europe (Paris, Munich, Sophia Antipolis, Budapest, Berlin), l'objectif de ce salon est de présenter les nouveautés et les évolutions technologiques en matière de tests automatisés. Des spécialistes en provenance de France, de Hongrie, d'Allemagne, d'Estonie, du Portugal, d'Italie, de Turquie, d'Espagne, de Pologne et de Suède y échangent lors de conférences autour de l'intelligence artificielle, de déploiements industriels de tests automatisés, des domaines DevOps et du BDD... entre autres ! Vous pourrez vous aussi rencontrer l'équipe Squash lors de la prochaine session du Club Qualité Logicielle. Organisée le 21 novembre prochain, cette journée inclura la réunion du Club Utilisateurs de Squash pour échanger autour de l'actualité et du futur de la suite Squash. En savoir plus sur le UCAAT
- Prochain Club Utilisateurs Squash : 21/11/2019
Créé en 2006, le Club Qualité Logicielle a pour vocation de réunir ses membres pour échanger autour de retours d’expérience afin de promouvoir la qualité logicielle et de participer à la normalisation et à la professionnalisation de l’activité. Cette session évoquera le test en mode Agile, l'approche DevOps et la formation aux métiers du test le matin. Le Club Utilisateurs Squash sera organisé tout au long de l'après-midi. Plus d'informations
- Squash invité lors du séminaire interne de début d'année de la SNCF
L'Equipe Squash était invitée au séminaire interne de début d'année de la SNCF : l'occasion de présenter une démo comprenant un cas d'usage en mode agile (à l'aide du plugin Xsquash et de Jira) avec automatisation (à l'aide de la suite Squash). Reproduite 5 fois, cette démo a intéressé un public composé d'administrateurs qui déploient Squash, de développeurs, d'intégrateurs qui utilisent l'API Squash, de managers et de PO/PM de l'usine logicielle. Chacun a pu poser des questions pertinentes tant sur le plan technique que fonctionnel en vue d'en savoir plus autour de Squash !
- Nouvelles catégories pour le Forum Squashtest
Le Forum Squashtest évolue pour répondre au mieux à vos questions, tout en prenant en compte les nouveaux aspects de l'offre Squash. Les catégories se distinguent donc sous 4 nouvelles catégories qui s'additionnent avec celles qui existaient déjà précédemment : "Présentez-vous" et "SKF + plugins IDE". Les nouvelles catégories et sous-catégories se distinguent comme tel : Référentiel de tests* --> Exigences --> Cas de test --> Campagnes --> Pilotage --> Administration --> Bugtrackers --> Xsquash* --> Installation & Base de données Tests automatisés* --> Espace Automatisation* --> Workflow* --> Runners* --> Junit* --> Cucumber* --> Robot Framework* Intégration dans une forge* --> Squash Execution Server --> Lien cas de test - tests automatisés --> API Rest Test Management* Gestion de la Communauté* --> Contributions --> Questions générales --> Propositions d'évolution* * les nouvelles catégories Accéder au Forum
- Questionnaire Squash 2019 – Vos retours d’utilisation en chiffres
Les 6 derniers mois de l’année 2019, il vous a été proposé de répondre à un court questionnaire pour vous permettre de partager vos retours d’utilisation autour des produits de la galaxie Squash. Ce rapport ne prend en compte que les réponses des personnes qui ont rempli le questionnaire en entier. Ces résultats ne sont donc pas forcément révélateurs de l’ensemble de la communauté des utilisateurs de Squash. A titre indicatif, voici le nombre mensuel de téléchargements de Squash sur l’année 2019 : - 4 500 téléchargements de Squash ou de composants pour le management de test - 180 téléchargements de Squash ou de composants pour l’automatisation de test - 60 téléchargements de Xsquash (via la Marketplace Atlassian). Et voici en chiffres les principaux enseignements à retenir de notre questionnaire : Quel(s) produit(s) de la galaxie Squash utilisez-vous ? 96% des répondants utilisent une version récente de Squash (la v.1.18 est sortie en juillet 2018). Les utilisateurs de Squash avec Jira 100% des répondants qui disent utiliser Squash et Jira, utilisent Jira en tant que bugtracker. Près de la moitié d’entre eux utilisent également le plugin Xsquash (sorti en juillet 2018). Combien de personnes utilisent Squash au sein de vos équipes? Près de la moitié des utilisateurs qui ont répondu travaillent au sein d’équipes comprenant un nombre restreint de testeurs (inférieur à 25). Quel(s) bugtracker(s) utilisez-vous ? Jira est toujours le bugtracker le plus utilisé avec Squash. A noter que la totalité des répondants qui utilisent Mantis fonctionnent avec des équipes de moins de 100 utilisateurs. Utilisez-vous l'Espace Exigences ? L’Espace Exigences de Squash est largement utilisé par les répondants (à hauteur de 86%). Dans quel(s) contexte(s) utilisez-vous Squash ? Le bilan est plutôt équilibré auprès de nos répondants quant à savoir s’ils utilisent Squash en contexte cycle en V ou en contexte agile. Info supplémentaire : 35% des utilisateurs en contexte agile ont répondu utiliser Xsquash. Faites-vous de l'automatisation de tests ? Squash, à travers son offre autour de l’automatisation de tests, offre une alternative intéressante sur ce secteur pour 30% des répondants qui disent pratiquer l’automatisation de tests. Quel(s) outils / langages / frameworks d'automatisation utilisez-vous ? (parmi les répondants qui automatisent des tests) La technologie orientée mots-clés est presque aussi répandue que le langage de programmation parmi nos répondants qui automatisent des tests (41% vs 52%). Quel(s) studio(s) utilisez-vous ? (parmi les répondants qui utilisent des studios) Parmi les répondants qui disent utiliser des studios pour implémenter des scripts automatisés, UFT et Ranorex sont largement plébiscités.
- Xsquash désormais compatible avec Jira Cloud
La suite Xsquash permet d'interfacer Squash avec Jira pour transmettre des informations automatiquement d'un outil à l'autre et travailler en mode Agile. Au cœur de Squash, le plugin "Xsquash4Jira" donne la possibilité de synchroniser les User Stories de Jira en exigences dans Squash. Côté Jira, "Xsquash" permet aux utilisateurs de suivre directement dans Jira l’avancement de la recette réalisée dans Squash sur leurs User Stories. Cet outil, disponible depuis 2018 sous forme de plugin, est téléchargeable gratuitement sur la Marketplace Atlassian pour Jira Server : https://marketplace.atlassian.com/apps/1219060/xsquash-agile-testing-with-oss-squash?hosting=server&tab=overview. Ce service est maintenant disponible pour la plateforme Jira Cloud. Optimisé pour l’environnement Jira Cloud, Xsquash est désormais disponible sous forme d’application hébergée chez Henix. Xsquash Cloud permet aux utilisateurs Jira disposant d’une licence Squash de récupérer dans Jira le suivi de la rédaction des cas de test couvrant leurs User Stories ainsi que les exécutions de ces derniers. Découvrez en images les fonctionnalités de Xsquash Cloud : o Configuration multi-serveurs de synchronisation : Xsquash Cloud permet à un administrateur de déclarer plusieurs serveurs de synchronisation issus de différentes instances Squash. o Configuration unitaire par projet : Xsquash Cloud se configure individuellement par projet depuis les paramètres du projet. Il est possible de sélectionner un serveur de synchronisation dans la liste et de modifier les noms des onglets qui récupèrent les données des cas de test et des exécutions. o Affichage d’un bloc Xsquash sur les demandes du projet : Un bloc Xsquash s’affiche sous le bloc Description de toutes les demandes Jira du projet. Il se compose de 2 onglets : - L’onglet "Cas de test Squash TM" liste dans un tableau le détail de tous les cas de test couvrant l’exigence synchronisée du ticket - L’onglet "Exécution Squash TM" liste toutes les exécutions de ces cas de test. o Détails des informations de l’onglet Cas de test Squash TM : L’onglet "Cas de test Squash TM" permet de consulter les données suivantes pour chaque cas de test : - Attributs - Description - Prérequis - Jeux de données - Pas de test - Statut de dernière exécution Depuis cet onglet, il est également possible d’accéder à la page de consultation des cas de test dans Squash. o Détails des informations de l’onglet Exécutions Squash TM : L’onglet "Exécution Squash TM" permet de consulter les données suivantes pour chaque cas de test exécuté : - Attributs - Jeux de données - Commentaires - Pas d’exécution - Statuts d’exécution Depuis cet onglet, il est également possible d’accéder aux pages de consultation des itérations, des cas de test et des exécutions dans Squash.
- Comment importer des Cas de test et des associations ?
Principes généraux : L'import de cas de test se fait à partir de fichiers aux formats Excel (.xls, .xlsx ou .xlsm) ou .zip (fichiers contenant un fichier Excel par cas de test, organisés dans une arborescence qui reflète l'arborescence des cas de test à créer, et assemblés dans un fichier .zip). Ces fichiers doivent avoir un format spécifique, le gabarit d'import peut être téléchargé depuis l'application. Le fichier d'import au format Excel permet d'importer à la fois les cas de test, les pas de test, les paramètres, les jeux de données et les associations cas de test / exigences (un onglet par type de données). Le fichier d'import au format zip permet d'importer les cas de test et les pas de test. Cet article détaillera uniquement l'import au format Excel. Pour importer un fichier de cas de test : 1. Allez dans l'espace 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 : 4. Une pop up "Importer au format Excel" s'ouvre dans laquelle vous pouvez : Choisir le format d'import (Excel ou zip) -> dans cet exemple Excel Télécharger les gabarits d'import pour chaque format Choisir le fichier à 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 le résultat de l'import des cas de test, pas de test, paramètres, jeux de données et associations cas de test / exigences apparaît. Il est possible de télécharger un bilan d'import avec le détails des lignes traitées en succès, avec réserve ou en échec : 6. Si l'option "Importer" a été choisie, les cas de test, pas de test, paramètres, jeux de données et associations cas de test / exigences sont insérés dans la base de données et les case de test apparaissent dans l'arborescence de l'espace cas de test. 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 les tableaux. - Les premières lignes dans chaque onglet (entêtes du tableau) indiquent la nature du champ alimenté avec les valeurs de la colonne. Les colonnes peuvent être dans n'importe quel ordre. - L'import se fait ligne par ligne. L'ordre des lignes n'a pas d'importance. - Les noms de champs de la première ligne 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 'TEST_CASES' du fichier d'import : ACTION (Obligatoire) > Détermine l'action à effectuer. Doit comporter les valeurs (ou lettres) suivantes : >> CREATE (C) : lors de la création d'un cas de test >> UPDATE (U) : lors de la mise à jour d'un cas de test TC_PATH (Obligatoire) > Chemin du cas de test du nom du projet jusqu'au nom du cas de test ex : /Nom du projet/Nom du dossier/Nom du cas de test Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". Si vous souhaitez mettre des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant :"\/". TC_NUM > Ordre du cas de test dans son dossier conteneur TC_REFERENCE > Référence du cas de test TC_NAME > Nom du cas de test TC_MILESTONE > Nom du ou des Jalon(s) associé(s) au cas de test. TC_WEIGHT_AUTO > 1 : Si le calcul de l’importance est automatique, en s'appuyant sur la valeur de la criticité des exigences rattachées. > 0 : si la valorisation de l’importance est manuelle. TC_WEIGHT > Code de l’Importance du cas de test :VERY_HIGH, HIGH, MEDIUM, LOW TC_NATURE > Code de la nature du cas de test : ATDD, BUSINESS_TESTING, NON_FUNCTIONAL_TESTING, PERFORMANCE_TESTING, SECURITY_TESTING, UNDEFINED, USER_TESTING TC_TYPE > Code du type de cas de test : COMPLIANCE_TESTING, CORRECTION_TESTING, END_TO_END_TESTING, EVOLUTION_TESTING, PARTNER_TESTING, REGRESSION_TESTING, UNDEFINED TC_STATUS > Code du statut de cas de test : APPROVED, OBSOLETE, TO_BE_UPDATED, UNDER_REVIEW, WORK_IN_PROGRESS TC_DESCRIPTION > Description du cas de test TC_PRE_REQUISITE > Pré-requis du cas de test TC_CREATED_ON > Date de création du cas de test TC_CREATED_BY > Login du créateur TC_LAST_MODIFIED_ON > Date de modification du cas de test TC_LAST_MODIFIED_BY > Login du dernier modificateur TC_CUF_ > Dans l'entête de colonne, indiquer le code du champ personnalisé associé au cas de test, précédé de TC CUF > Dans la colonne, mettre la valeur du champ personnalisé Description de l'onglet 'STEPS' du fichier d'import : ACTION (Obligatoire) > Détermine l'action à effectuer. Doit comporter les valeurs (ou lettres) suivantes : >> CREATE (C) : lors de la création d'un pas de test >> UPDATE (U) : lors de la mise à jour d'un pas de test TC_OWNER_PATH (Obligatoire) > Chemin vers le cas de test propriétaire du pas de test Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". S'il y a des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant : "\/". TC_STEP_NUM > Numéro d’ordre de l’étape de test TC_STEP_IS_CALL_STEP > 0 : si l’étape est une action step > 1 : si l’étape est une call step (appel à un cas de test de la base) TC_STEP_CALL_DATASET Dans le cas de l'appel à un cas de test existant : > INHERIT : si l’option prise est de ne pas choisir de jeu de données, le cas de test appelant hérite des paramètres du cas de test appelé > sinon, indiquer le jeu de données qui a été choisi TC_STEP_ACTION > Action de l’étape > Ou bien CALL/Project/chemin vers le cas de test appelé si c’est un appel à un cas de test TC_STEP_EXPECTED_RESULT > Résultat attendu pour l’étape TC_STEP_CUF_ > Dans l'entête de colonne, indiquer le code du champ personnalisé associé au cas de test, précédé de TC_STEP_CUF_ > Dans la colonne, mettre la valeur du champ personnalisé. Description de l'onglet 'PARAMETERS' du fichier d'import : ACTION (Obligatoire) > Détermine l'action à effectuer. Doit comporter les valeurs (ou lettres) suivantes : >> CREATE (C) : lors de la création d'un paramètre >> UPDATE (U) : lors de la mise à jour d'un paramètre TC_OWNER_PATH (Obligatoire) > Chemin vers le cas de test propriétaire du paramètre Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". S'il y a des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant : "\/". TC_PARAM_NAME > Nom du paramètre TC_PARAM_DESCRIPTION > Description du paramètre Description de l'onglet 'DATASETS' du fichier d'import : ACTION (Obligatoire) > Détermine l'action à effectuer. Doit comporter les valeurs (ou lettres) suivantes : >> CREATE (C) : lors de la création d'un jeu de données >> UPDATE (U) : lors de la mise à jour d'un jeu de données TC_OWNER_PATH (Obligatoire) > Chemin vers le cas de test propriétaire du jeu de données Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". S'il y a des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant : "\/". TC_DATASET_NAME (Obligatoire) > Nom du jeux de données TC_PARAM_OWNER_PATH > Chemin vers le cas de test propriétaire du paramètre. Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". S'il y a des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant : "\/". > Cette colonne est nécessaire dans le cas de paramètres venant de cas de test appelés par le cas de test propriétaire du dataset. TC_DATASET_PARAM_NAME (Obligatoire) > Nom du paramètre pour lequel la valeur sera renseignée>br /> TC_DATASET_PARAM_VALUE > Valeur correspondante pour le couple {jeux de données | paramètre} spécifié Description de l'onglet 'LINK_REQ_TC' du fichier d'import : REQ_PATH (Obligatoire) > Chemin de l'exigence depuis le nom du projet jusqu'au nom de l'exigence Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". S'il y a des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant : "\/". REQ_VERSION_NUM (Obligatoire) > Numéro de la version d’exigence à lier TC_PATH (Obligatoire) > Chemin du cas de test depuis le nom du Projet jusqu’au nom du cas de test Attention : il ne doit pas y avoir d'espace avant ou après le séparateur "/". S'il y a des "/" dans les noms de dossier ou de cas de test, ils doivent être neutralisés par un anti-slash juste avant : "\/".
- Tutoriel - Astuces Squash TM
Cet article présente certaines fonctionnalités open source de Squash TM, facilement accessibles et qui permettront à vos équipes de tests d’optimiser la gestion des projets. 1. Version des exigences 2. Modification en masse des attributs des cas de test & exigences 3. Drag & drop Version des exigences Le versioning d’exigences permet de gérer efficacement son patrimoine de tests en créant différentes versions pour une même exigence. Il est courant que les spécificités évoluent au cours du cycle de développement. Le versioning des exigences est un bon moyen pour assurer le suivi d’évolution des documents de spécification et les différents cycles de test. Chaque version d’une exigence peut donc correspondre à une nouvelle version des spécifications ou à une nouvelle phase de test. Tous les champs d’une nouvelle version sont modifiables. Vous pouvez ainsi associer une nouvelle version d’une exigence sur un projet dont l’application a évolué et qui place l’exigence à un niveau de criticité plus élevé. Pour créer une nouvelle version d’une exigence, il suffit de se rendre sur la page de consultation d’une exigence et de cliquer sur [Créer une nouvelle version]. Une pop-up apparaît, vous demandant de confirmer la création de la nouvelle version : Deux cases à cocher vous demandent de spécifier les conditions de création de la nouvelle version d'exigence : Reprendre les liens entre versions d'exigences non-obsolètes : La nouvelle exigence dupliquera les liens avec les autres versions d'exigences de l'ancienne version vers la nouvelle version. Les liens vers l'ancienne version sont conservés. Comme indiqué, seuls les liens vers des exigences non obsolètes sont dupliqués. Reporter les cas de test attachés vers la nouvelle version de l'exigence : Les cas de test attachés à l'ancienne version d'exigence seront désormais rattachés à la nouvelle version. Les anciens rattachements sont supprimés : il est en effet impossible pour un cas de test d'être rattaché à deux versions différentes d'une même exigence. En confirmant, vous retournez sur la page de consultation, sur laquelle apparaît un nouveau numéro de version dans le champ dédié. La nouvelle version créée est considérée comme la version active. Ainsi, lors de l’association de cas de test à une exigence par exemple, la dernière version sera sélectionnée par défaut. L’historique des versions est disponible et consultable via une interface de niveau 2, permettant de visualiser l’ensemble des modifications apportées au cours de la création des différentes versions. NB : Deux versions d'une même exigence ne peuvent être associées à un même cas de test. Modification en masse des attributs des cas de test & exigences 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 et depuis l’espace Campagne. 1. Modification en masse de cas de test depuis l’espace Cas de test Pré-requis : l’utilisateur doit bénéficier des droits d’écriture sur les cas de test à modifier. La modification simultanée de plusieurs cas de test peut se faire sur les attributs suivants : - L’importance - Le statut - Le type - La nature 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. NB : pour les exigences, la modification en masse peut se faire sur les champs suivants : criticité, catégorie et statut. Le procédé est le même, à partir de l'écran de recherche des exigences. 2. Modification en masse des statuts des cas de test depuis l’espace Campagne Dans l’espace Campagne, dans le plan d’exécution d’une itération ou d’une suite de tests, il est possible de modifier le statut de plusieurs cas de test de façon simultanée. Il suffit de sélectionner les cas de test dont le statut est à modifier, cliquer sur le bouton [Statut], sélectionner le statut à associer et confirmer. Drag & drop Un des grands avantages de Squash TM est sa facilité de prise en main et sa simplicité d’utilisation. Parmi les fonctionnalités qui vous faciliteront votre travail de recette, il y a notamment le « drag & drop » pour associer les différents objets entre eux. 1. Association des cas de test et des exigences Dans les pages de consultation des exigences et des cas de test, un encart dédié vous permet de consulter réciproquement les cas de test vérifiant une exigence et les exigences vérifiées par un cas de test. Lorsque vous souhaitez lier une exigence à un cas de test par exemple, il vous suffit de cliquer sur le bouton [+] qui vous permet d’accéder à une interface de niveau 2. A partir de cette fenêtre, il vous suffit de glisser les exigences (ou des dossiers) depuis l’arborescence dans le tableau de la fenêtre principale pour faire les liaisons avec le cas de test. La même manipulation se fait depuis l’espace Exigence. 2. Association de cas de test au plan d’exécution de campagne Dans l’espace Campagne, l’association entre les cas de test et les campagnes, itérations et suites de tests, est possible selon le même procédé, à partir de l’onglet [Plan d’exécution], puis en cliquant sur [Ajouter]. 3. Appel d’un cas de test L'appel d'un cas de test permet d'utiliser des tests déjà existant lors de la création de nouveaux tests. Vous pouvez ainsi exploiter votre patrimoine et l'alimenter intelligemment, en vous appuyant sur l'existant. Dans l’espace Cas de test, l’appel d’un cas de test se fait également d’un simple « drag & drop » depuis la bibliothèque des cas de test jusque dans l’onglet [Pas de test] de la page de consultation. Un nouveau pas de test est alors créé, qui indique l'appel du cas de test. Le pas de test est créé à la fin des cas de test existants, et peut ensuite être déplacé à l'endroit désiré au sein du cas de test. 4. Liens entre les exigences Il est possible de lier entre elles les exigences, et de personnaliser les types de ces liens grâce au « drag & drop ». Un pavé est prévu à cet effet dans la page de consultation (cf. capture d’écran ci-dessous). Il permet de consulter les exigences liées et d’ajouter de nouvelles exigences depuis la bibliothèque en glissant simplement les exigences depuis la bibliothèque vers le tableau des exigences liées. Une popup s'ouvre alors pour vous demander le type de lien qui lie les deux exigences. Le type de lien est paramétrable dans l'espace Administration.
- Henix rejoint la Fondation Robot Framework
En tant que commiter principal de la suite open source Squash, Henix place l'open source au cœur de ses valeurs. Acteur de référence pour l'automatisation de tests en France avec Squash, Henix marque son engagement comme contributeur autour du projet Robot Framework en devenant membre de la Robot Framework Foundation. Robot Framework est un outil open source d'automatisation dont la communauté d'utilisateurs s'agrandit d'année en année. La Robot Framework Foundation est un consortium à but non lucratif qui favorise la croissance de Robot Framework. Elle est composée d'entreprises ayant un intérêt commun pour assurer son développement. Cliquez ici pour en savoir plus sur la Robot Framework Foundation.











