Programmez: La gestion de ses tests avec un ALM

Les ALM (Application Lifecycle Management) sont l’outil des testeurs par excellence de par leurs multiples fonctionnalités liées au métier du test !

Les ALM proposent en effet un répertoire de test, la création de liens entre les exigences, la gestion de campagne de test, le suivi des différentes exécutions et généralement une gestion des anomalies !

Afin de comprendre comment utiliser leur rôle et leur puissance je vous propose, dans cet article, de découvrir un exemple de gestion d’un projet de test avec ALM français, proposant de nombreuses fonctionnalités et une forte paramétrisation : XStudio !

Attention, dans cet article nous ne parlerons pas de gestion des anomalies.

De même, l’ensemble des fonctionnalités de XStudio ne sera évidemment pas couvert dans cet article, l’objet n’étant pas de faire une présentation exhaustive de ce bel outil mais bien de montrer comment se servir d’un ALM.

Nous prendrons, dans cet article, pour exemple de projet/produit de test le site/blog de « La taverne du testeur », blog francophone dédié au test proposant régulièrement des articles de différents professionnels du test !

Afin de bien comprendre l’ensemble des étapes du projet de test et d’initialisation de notre ALM nous allons partir d’une feuille blanche/ Nous allons donc passer par différentes phases avant de pouvoir exécuter régulièrement nos différents tests (manuels ou automatisés) :

• Initialiser l’ALM XStudio
• Initialiser les informations pour son projet/produit à tester
• La création des tests manuels
• La création d’une campagne de test
• Les tests automatisés
• Les bilans des tests

L’initialisation de l’ALM XStudio

Lorsque l’on commence un projet de test dans un ALM il faut tout d’abord, si ce n’est pas déjà fait, paramétrer son ALM.

On commence donc par créer la base de données qui sera utilisée (c’est automatique avec XStudio lors de son premier lancement).

Suite à cela il faut créer l’ensemble des paramètres nécessaires au bon fonctionnement de l’outil dans son environnement.

On peut le faire assez facilement avec l’IHM lorsque l’on est connecté en administrateur. Pour notre projet de test nous avons créé :

• Une entreprise : L’association de la taverne du testeur
• Une équipe avec des droits d’accès au système à tester (SUT) et aux exigences. C’est comme ça qu’on définit ce qui est visible par chaque équipe.
• Des membres de l’équipe (chaque utilisateur pouvant appartenir à plusieurs équipes).

S’ensuit alors une gestion des profils utilisateurs.

Dans XStudio, pour pouvoir créer des utilisateurs il faut, en amont, avoir au moins 1 équipe et 1 entreprise. Pour notre projet, nous avons créé des analystes métiers, testeurs et une fonction transverse. Comme vous pouvez le voir, pour chaque utilisateur, il est possible de définir des informations générales et un profil :

Au final, nous avons nos équipes et nos utilisateurs qui sont bien répartis :

Initialiser les informations pour son projet/produit à tester

Maintenant que nous avons notre base de données, notre entreprise et nos utilisateurs il faut se pencher sur ce qui nous intéresse, notre site de la taverne du testeur !

Pour cela il n’est pas question de créer directement des tests. La puissance d’un ALM c’est de créer des relations entre différents types d’objets… Ce dans quoi XStudio excelle !

Nous décidons donc de créer 2 SUT (System Under Test). Ces 2 systèmes sont le site web de la taverne « latavernedutesteur.fr » et l’application mobile de la taverne.

Dans XStudio, il est possible d’ajouter de nombreuses informations sur les SUT. On peut, par exemple, proposer des customisations des bilans automatiques liées à ces SUT.

Maintenant que ces systèmes sont créés, il est temps de s’attarder sur les exigences. La traçabilité entre les exigences et les tests est obligatoire si on veut assurer une bonne couverture de test mais aussi savoir où se trouvent les points faibles de notre application (ou site web).

Nos 2 SUT étant liés à la taverne du testeur, nous avons des exigences communes (charte graphique, les pages secondaires), des exigences spécifiques à l’application mobile (performances) et au site web (la page d’accueil et la recherche). Cela tombe bien, il n’y a pas besoin de dupliquer ces exigences dans XStudio ! Si une équipe est en charge du site web, et une autre de l’application mobile, toutes deux verront les exigences communes et leurs exigences respectives spécifiques.

De même, chaque exigence peut être enrichie de nombreuses informations comme :

• Un risque (positionné à la main ou via un wizard très simple – voir capture ci-dessous)
• Une information sur son type : fonctionnel ou non fonctionnel (si vous me suivez, vous savez que je prête une grande attention au non fonctionnel !)
• D’autres paramètres que nous n’avons pas utilisés ici

Un autre point important dans XStudio est la possibilité de vérifier que les exigences ont bien été validées et revues mais aussi qu’elles sont bien complètes :

Lorsque ces exigences sont créées il faut les relier aux SUT comme il a été pensé lors de la création des exigences. Il est possible de le faire directement depuis chaque exigence mais aussi depuis les SUT afin d’aller plus vite.

Lorsque tout est fait on peut voir quel est la couverture des SUT par les exigences. Attention, cette couverture n’est pas de 100% si les exigences ne sont pas finalisées !

Un SUT sera automatiquement déclaré couvert en termes d’exigences à partir du moment ou une ou plusieurs exigences lui seront liées. Mais attention, vous avez la possibilité de raffiner cela manuellement si par exemple vous savez qu’il vous manque encore des exigences.

Note : ce principe est surtout valable au niveau des tests : si une exigence est liée à 10 tests mais que vous estimez que 20 tests seront nécessaires à sa couverture, je vous conseille de manuellement positionner le curseur sur 50%. Ça vous permettra d’avoir des métriques de couverture et de qualité fiables.

La création des tests manuels

Maintenant que les exigences sont créées et liées au SUT il est temps de créer ses tests. Même s’il est évidemment possible d’écrire ses tests manuels directement sous XStudio ou de les importer en Excel ou XML, nous avons décidé de concevoir nos tests avec l’outil Yest de Smartesting. Cet outil d’ATDD (ou MBT) permet de concevoir des scénarios tests rapidement tout en assurant une couverture de l’ensemble des cas de test que nous souhaitons exécuter.

Sur cette image vous voyez à gauche la liste des tests générés, au centre les étapes de test qui seront présentes dans XStudio et à droite le parcours ayant permis la génération du cas de test.

Pour pouvoir intégrer ses tests générés dans Yest il faut faire un Export et réimporter le fichier Excel généré dans XStudio. Cela demande quelques manipulations dans Yest mais se fait assez rapidement. Il est également possible d’avoir, à terme, une synchronisation plutôt qu’un import (XStudio expose une API REST)

En se rendant sur un test importé, nous remarquons que les tests correspondent bien à ce qui a été généré sur XStudio (les noms du screenshot précédent en sont une preuve).

La création d’une campagne de test

Maintenant que les tests sont créés, il est possible de créer des campagnes. Chaque campagne comporte une sélection de test à exécuter. Cette liste est ordonnée car l’ordre d’exécution peut être critique. Plusieurs outils facilitent la sélection des tests (recherche de tous les tests couvrant un SUT, couvrant une sélection d’exigences ou encore tous les tests permettant de vérifier un certain nombre de bugs marqués comme résolus).

Lorsque l’on veut exécuter les tests de sa campagne, on crée une session. Chaque session est paramétrable ; on peut définir sur quel SUT la campagne a lieu, qui doit exécuter les tests mais aussi des paramètres liés à l’automatisation des tests (ex : sur quelle machine exécuter ses tests, avec quelle configuration, sur quel environnement de test etc.)

Les sessions de XStudio permettent d’avoir un historique d’exécution des tests et des campagnes.

L’exécution des tests manuels dans XStudio peut se faire de plusieurs manières (5 interfaces sont disponibles au choix) et, tout comme pour chaque ALM, il est possible de valider (ou d’invalider) chaque étape de test et/ou chaque test en fournissant un commentaire (optionnel) et éventuellement un ou plusieurs fichiers (capture d’écran, log etc.) qui serviront de preuve.

Lorsque certains tests sont en échecs, il est également possible, dans XStudio, de générer automatiquement des campagnes résiduelles afin de ne ré-exécuter que les tests qui étaient en échec.

A noter : la création de campagne résiduelles propose plusieurs options et pas uniquement l’exécution des cas de test en échec lors de leur dernière exécution. Cette option est particulièrement intéressante en fin de projet pour relancer tous les tests « à risque ».

Les tests automatisés

XStudio est un ALM qui a été conçu pour s’interfacer très facilement avec n’importe quel outil de test.

Pour notre projet de test de la taverne du testeur, nous avons choisi d’avoir des tests automatisés avec Agilitest.

Agilitest est un des rares outils qui me permette d’automatiser des tests très facilement sans avoir de compétences techniques.

Les tests générés sont des fichiers ats scripts :

Il est alors temps de référencer ces tests « automatisés » dans XStudio. On commence par créer une catégorie de tests que l’on associe à l’un des 80 connecteurs existants ; ici on choisira «agilitest.jar ».

Nous créons ensuite un dossier « temporaire », un test « Ouvrir_article.class » et un cas de test « default »

Suite à cela nous avons créé une campagne avec le test précédemment créé. Cette campagne correspond à un scope de test et sera exécutable plusieurs fois sur des cibles différentes avec des configurations différentes.

Il faut alors, comme pour les tests manuels, créer une session d’exécution en sélectionnant le bon SUT :

Il faut également fournir une configuration correcte, dans notre cas :

• Test root path = C:\agilitest-projects
• ATS path   = C:\agilitest-ats
• Java JDK path  = C:\Users\eric\.agilitest\tools\jdk-10.0.2

Il ne reste plus alors qu’à exécuter la session. Les résultats sont ensuite présents dans l’onglet « résultat ».

Les fichiers générés par le système d’automatisation (logs, rapports…) sont également stockés sur XStudio.

A noter :

• lors de l’exécution des tests on peut utiliser ou créer une configuration qui sera réutilisable.
• Maintenant que l’on a une configuration qui est validée (avec un seul test), on peut même laisser XStudio « découvrir » tout seul tous les tests agilitest disponibles ce qui nous évitera de les référencer à la main comme montré précédemment. Cela permet notamment de mettre à jour automatiquement notre base de test automatisés dans XStudio.

Les bilans des tests

Enfin, que serait les tests sans bilan des tests ?

XStudio propose de nombreux indicateurs qui sont mis à jour en temps réel avec l’exécution des tests. On peut par exemple avoir les résultats de la campagne de la taverne avec de nombreuses indications (tests, étapes, personne ayant exécuté les tests…) :

De plus, XStudio va plus loin et propose un suivi des tests en général.

Attention, à partir de maintenant, les screenshots ne seront plus pris par rapport à notre projet afin de proposer des bilans avec un vrai historique.

J’apprécie par exemple son système de « pyramide des tests » qui pousse à intégrer les tests unitaires également à XStudio (qui intègre évidement des connecteurs JUnit, CUnit etc. natifs. Ceci est facile à mettre en place et je ne peux que recommander l’intégration de votre ALM avec un système d’Intégration Continue (Facile à faire avec XStudio via XContinuousIntegration fourni par défaut).

Dans la même veine j’aime également beaucoup la fonctionnalité de complétude d’un test. Concrètement, cela revient à considérer qu’un test est vraiment fini qu’à partir du moment où certains critères définis sont bien effectués. On peut par exemple penser à une revue validée. Dans le cas contraire le test n’est pas considéré comme fini à 100%. De la même manière, Un test non-exécutable ne couvre pas à 100%. Cela permet notamment de savoir quel est le vrai travail qui reste à faire sur les tests.

Voici à quoi ressemble une couverture dans XStudio (avec des règles par défaut) :

Enfin, chaque SUT est également couvert, avec des tests qui sont exécutés ou non. On obtient encore des graphiques assez facilement (paramètre par défaut) :

XStudio propose également un radar qui est une métrique très prisée par le « Top management ». Ce radar est lié à un SUT et propose une synthèse de chaque métrique. On peut remarquer que ce type de graphique est utilisé dans de nombreux domaines afin de déterminer les forces et faiblesses d’équipes, personnes ou logiciel (ex : rapport d’audit ou de maturité) :

Evidemment, il est également possible de générer des rapports imprimables incluant ces indicateurs et graphiques (aux format Html, Pdf, Word, Excel) ce qui facilite le reporting à la hiérarchie.

Je pourrais également parler de l’indicateur de progression des résultats, qui montre, sur un temps donné, l’évolution des couvertures de test et des exigences ainsi que la « Qualité ». L’ensemble de ces courbes permet d’anticiper d’éventuels retards mais aussi d’en connaitre la cause et donc de prendre les décisions adaptées.

• Conclusion

Les ALM sont des outils qui peuvent être difficiles à prendre en main, principalement lorsque l’on n’est pas testeur. Leur apport est en revanche extrêmement intéressant. La centralisation des activités de test, les liens créés en leur sein entre différents composants (exigences, tests, campagnes, anomalies, autres outils…) leur capacité à archiver et savoir ce qui a été fait en font des outils très riches et quasiment indispensables dès lors où l’on veut faire de l’amélioration continue, que l’on souhaite pouvoir montrer quel est le travail effectué avec les tests et donc pouvoir évaluer sur des critères précis un niveau de qualité.

Un grand merci à Eric Gavaldo, concepteur de XStudio et gérant de la société XQual, pour son aide et sa contribution à cet article !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles