Synchronisation avec les gestionnaires du cycle de vie des applications (ALM)

Application LIfecycle Manager (ALM) synchronization

 

MaTeLo est totalement intégré avec des ALM comme HP ALM Quality Center. De façon générale, d’un seul clic, il est possible de créer ou mettre à jour, à partir d’un modèle MaTeLo, tout le référentiel ALM, de façon optimisée, sans avoir besoin d’aller dans l’ALM. Les ressources MaTeLo sont synchronisées en multi utilisateurs dans l’ALM. La synchronisation est bidirectionnelle et les modifications sur l’ALM sont portées dans le modèle.

Connexion aux ALM

MaTeLo peut se connecter à différents gestionnaires de cycle de vie d'applications comme :

HP ALM Quality center, Squash TM, IBM Doors, Test Link et en option Team Foundation Server (TFS), Polarion, et MIcrofocus Silk Central.

Pour se connecter au référentiel ALM, il est nécessaire de renseigner les informations de connexion identiques à celles de la connexion au client de l'ALM. Les droits utilisateurs dans l'ALM sont gérés de façon identique dans MaTeLo.

 

Import Export des Exigences

A partir du Test Repository Explorer, il est possible de naviguer dans l’arborescence des exigences de l’ALM, de visualiser le contenu des exigences, et de l’importer directement dans le modèle MaTeLo. Au moment de la génération des cas de tests, les exigences qui auront été déposées sur les transitions MaTeLo, sont associées aux cas de test générés par MaTeLo, et la traçabilité Exigences/Cas de Test est assurée dans l’ALM.

 En cas de modification, d’ajout ou suppression d’exigences existantes un assistant d’import-export demande la confirmation de mise à jour du modèle ou du référentiel. Cet assistant indique ce qui est nouveau, en conflit par rapport à une exigence de même identifiant mais qui a évolué, et ce qui a été supprimé entre la version des exigences ALM et la version des exigences MaTeLo. L’utilisateur, par défaut, peut accepter les modifications pour chaque exigence.

 

 

 

Export des cas de test dans TestPlan

Les cas de test,correspondent à différents ensembles de transitions présents dans une macro chaîne optimisés pour une réutilisabilité maximum. Les cas de test sont générés en temps réel lors de la conception du modèle et correspondent aux transitions en série, avec autant de steps de transitions taggués comme step (cf §Step de test). Cette décomposition permet de garantir :

  • que tous les scenarios de test possibles, incluant les boucles, les conditions,
  • les branches, les sous états pourront utiliser une succession de ces cas de test déjà existants pour définir le parcours,
  • qu’à chaque regénération de scenarios (Suite de test), les même cas de test sont utilisés,
  • que les cas de test sont réutilisables au maximum,
  • qu’il n’y ait aucun doublonnage de steps de test dans le référentiel.

 

Nommage automatique des cas de test

Par défaut, les cas de test sont nommés automatiquement, en prenant un préfixe, puis le nom de la macro chaine dans laquelle ils se trouvent, puis, la concaténation des transitions « steppées » qu’ils traversent.
D’autres règles de nommage sont proposées et il est possible de renommer manuellement un cas de test.

Création des dossiers de Test Case

L’arborescence des dossiers qui contiennent les macro- chaines de MaTeLo et leurs cas de test associés, est synchronisée en créant la même arborescence des dossiers qui contiennent les cas de test dans Test Plan.

Mise à jour bi-directionnelle des cas de test.

En cas de mis à jour du modèle, les cas de test du référentiel (ALM QC) sont automatiquement modifiés pour refléter la mise à jour.
En cas de modification manuelle des cas de test dans le référentiel ALM, les modèles MaTeLo se mettent à jour automatiquement lors de la resynchronisation. Cette mise à jour inclus en outre la modification du nom du step, l’ajout, la suppression ou la modification de l’ordre des steps. .
L’import d’un cas de test du référentiel qui a été généré avec MaTeLo importe les modèles et sous modèles qui ont permis de générer les cas de test importés.

Synchronisation des paramètres des cas de test

L’ensemble des inputs utilisés comme données structurées de stimulation, ou outputs pour la vérification, se transforment lors de l’export des cas de test de MaTeLo vers l’ALM, en paramètres du module TestPlan. Les inputs deviennent des paramètres de stimulation du step (Colonne Description du step), et les outputs deviennent des paramètres ALM de la colonne Vérification. Ces paramètres ne sont pas valorisés dans le TestPlan. La bidirectionnalité est aussi assurée.

Export des suites de test générées par MateLo dans TestLab

Toutes les suites de test générées par MaTeLo sont importables par glisser déplacer dans l’arborescence des dossiers du module TestLab. Dans le cas ou la suite de test fait appel à un cas de test existant dans le référentiel TestPlan, le cas de test TestPlan est instancié dans la suite de test. Si le cas de test n’est pas encore présent, il est ajouté dans le TestPlan, puis instancié dans le TestLab.
La valorisation des paramètres utilisés dans les cas de test du module TestPlan est réalisée automatiquement dans les cas de test instanciés gérés dans le TestLaB.

Import des suite de test déjà générées par MaTeLo dans un nouveau projet

Afin de pouvoir regénérer des suites de test liées à des stratégies MaTeLo, l’import des suites de test depuis Testlab vers MaTeLo permet de créer un nouveau projet MaTeLo ou mettre à jour le projet courant, afin de disposer de toutes les ressources MaTeLo (Exigences, Modèles, Types, Données, Fonctions de traitement, automatisation,…) ainsi que de la stratégie précédemment utilisée pour la regénération.

Synchronisation des ressources MaTeLo dans les ressources de l’ALM

A chaque fois qu’un cas de test, ou une suite de test est synchronisé dans le TestPlan ou le TestLab, l’ensemble des ressources MaTeLo nécessaires à leur regénération est stocké dans les ressources de l’ALM et est associé aux éléments de l’ALM (TestCase, TestStep, Paramètres, TestSuite, Valorisation) Ces données sont librement accessibles pour les autres utilisateurs, à travers la vue « Test Repository Explorer » afin de maximiser la réutilisation des ressources MaTeLo entre tous les utilisateurs et permettre d’utiliser un dictionnaire de données commun. Les données gérées dans les ressources sont :

Les chaines, incluant les dossiers et l’arborescence

Les types utilisés dans les données MaTeLo

  • Les données MaTeLo (inputs, outputs, GV, constantes)
  • Les fonctions de traitement
  • Les attributs
  • Les fichiers et pièces jointes utilisés par MaTeLo, ou stockés localement dans le projet, notamment les scripts Selenium, bibliothèque UFT, fichiers de données Excel, et les jobs Talend permettant le lien avec le système d’information.

Modification des ressources MaTeLo depuis L’ALM

   Pour les éventuels besoins d’administration, les ressources MaTeLo stockées dans le module ressource de l’ALM sont modifiables en uploadant directement les ressources MaTeLo concernées au format XML dans le module Ressource de l’ALM. La même arborescence que celle des ressources du Test repository Explorer est disponible. Les fichiers xml sont compatibles avec les assistants d’import/export de MaTeLo. 

Définition du niveau step de test

Le step (ou pas de test) de test est intégré pleinement dans la stratégie de génération des cas de test issus de MaTeLo. Chaque transition possède une propriété « Test Step » permettant de tagger la transition en transition-step. A toute macro chaine MaTeLo correspond un ensemble de cas de test. Les cas de test contiennent autant de steps que de transitions en série dans la macro chaine, qui sont taguées en tant que Test Step. Dans le cas où une macro chaîne ne contient aucun step de test il n’y a pas de cas de test associé à la macro chaine. Par exemple dans le modèle ci-contre, il n’existe aucune transition taguée comme step, il n’y aucun cas de test résultant. Ce modèle permet d’indiquer simplement à MaTeLo l’enchainement des processus, mais ne contient pas d’actions à faire. Les actions de stimulation seront réalisées dans les macro chaînes qui contiennent les pas de test. Cette organisation autour du step de test permet les avantages suivants :

  • Les cas de test ne contiennent que des steps utiles à la stimulation et vérification à réaliser sur le système par le testeur.
  • Ils ne contiennent pas de step vides ou inutiles qui viendraient polluer le testeur ou l’automate.

Les transitions vides permettent de réaliser les stimulations intermédiaires, ou du câblage de logique combinatoire, ou même de l’organisation graphique de modèle, que le testeur manuel n’a pas nécessairement à sa connaissance. Dans la pratique, il est courant de n’avoir que 30% des transitions tagguées comme step de test.

Mise à jour des cas de tests

A chaque modèle correspond un ensemble de cas de test de MaTeLo. Tant que le modèle n’évolue pas, il n’y a aucune évolution sur les cas de test dans l’ALM. Le grain atomique des cas de test MaTeLo permet d’être réutilisé par tous les scenarios, qui utilisent les cas de test correspondant au modèle. L’utilisateur pourra générer selon autant de stratégies souhaitées avec la même base de cas de test.

En cas de modification du modèle : ajout/suppression/modification de transition-step dans une macro chaine, MaTeLo identifie les cas de test à modifier, et les remplacera par les nouveaux cas de test, sans faire évoluer les cas de test qui n’ont pas besoin de l’être.

En cas d’activation de la gestion des releases de Baseline dans l’ALM, les cas de test sont montés en version dans l’ALM.

Mise à jour des suite de test

Les suites de test sont générées grâce aux algorithmes de stratégie de test de MaTeLo, et sont stockées dans l’arborescence des scenarios. En cas d’évolution du modèle, de nouveaux cas de test peuvent être modifiés, et les suites de test peuvent devenir non fonctionnelles ou appeler des cas de test devenus impossibles à exécuter.

Afin de mettre à jour les suites de test, il est possible de les régénérer avec les paramètres de stratégie pouvant être enregistrés dans MateLo. Les suites de test réutilisent les cas de test existants.

Mise à jour des paramètres

Les cas de test générés depuis des modèles MaTeLo qui contiennent des données créent automatiquement les structures des paramètres ALM non valorisés. La valorisation des paramètres se fait au niveau de la suite de test. En cas d’évolution des structures de données MaTeLo (inputs, outputs), les paramètres de l’ALM sont automatiquement mis à jour dans les cas de test existants.

Mise à jour des exigences et de la traçabilité

Les exigences sont synchronisées entre l’ALM et MaTeLo. En cas de création/modification d’une exigence dans MaTeLo, l’exigence est créée ou mise à jour dans l’ALM. En fonction des droits d’administration donnés à l’utilisateur, la mise à jour ou la création peut être restreinte. La traçabilité des exigences avec MaTeLo est assurée grâce au dépôt d’une exigence sur une transition. La traçabilité est mise à jour lors des modifications.

Mise à jour des ressources

A chaque ressource ALM est associée la ressource MaTeLo qui a permis de générer la ressource ALM. Les ressources MaTeLo sont stockées dans le module ressource de l’ALM, et sont synchronisées avec le modèle MaTeLo.

Gestion de pièces jointes

Les pièces jointes comme les documents office, les scripts, des fichiers de données associées à un modèle MaTeLo sont stockées dans le dossier du workspace (stockage local Windows) du projet MaTeLo. Ces documents peuvent être mis dans une arborescence de dossiers spécifiques. Lors de la synchronisation du modèle dans l’ALM, les documents, pièces jointes et leur arborescence sont synchronisés automatiquement dans le module ressource de l’ALM.

MaTeLo gère un nombre très important d’options, créées pour répondre à 15 ans d’utilisation de Model-Based Testing dans le domaine des tests industriels et des systèmes d’information.