1.     Mon expérience avec les référentiels de tests à reprendre

Sur plusieurs des projets sur lesquels j’interviens comme consultante Testing, j’ai dû reprendre des référentiels de tests (manuels) pour les remettre à jour fonctionnellement, améliorer la cohérence des tests, supprimer les doublons, faciliter leur maintenance ultérieure et dans certains cas préparer leur automatisation. L’objectif est souvent de reprendre ces référentiels dans le contexte d’une migration technique ou d’une évolution applicative.

Depuis octobre 2019, j’utilise l’outil Orbiter de Smartesting, qui m’a permis de gagner beaucoup de temps sur cette activité, et aussi de voir comment l’IA pouvait être utilisée dans les activités de test.

Différentes raisons conduisent à analyser et optimiser un référentiel de test :

L’exploration des suites de tests : c’est la première nécessité pour un testeur qui consulte dans un grand référentiel de test peu familier. Le turnover induit souvent l’arrivée de nouveaux testeurs et donc le besoin de leur montée en compétence rapide sur l’application. Dans le cas de référentiel de test existant depuis plusieurs années et peu maintenu, le support d’un outil d’analyse du référentiel est précieux.

La mise à jour du référentiel de tests : afin de les rendre plus faciles à maintenir, à utiliser et à comprendre.  Cela implique généralement des changements tels que : la mise en place de terminologies et d’abréviations cohérentes, la standardisation de la description des étapes de test (steps), la détection et la suppression des tests redondants, la fusion d’étapes de test similaires en une étape paramétrée et le regroupement des tests semblables en suites.

L’automatisation des tests : nécessite des cas de test uniformes et cohérents afin de faciliter sa mise en place. De là, une analyse et une reprise du référentiel de test peuvent être un bon prérequis à l’automatisation et faciliter son implémentation.

2.    L’utilisation de l’outil Orbiter

Figure 1 : L’outil Orbiter

Techniques :

L’outil regroupe différentes techniques de machine learning, de clustering et d’algorithmes d’analyse des phrases en langage naturel correspondant aux étapes de test, pour le regroupement des tests par similarité et l’aide au refactoring et à la paramétrisation des étapes de tests.

Interconnectivité d’Orbiter avec les outils de test :

Dans le cadre de mes expérimentations, j’exporte les cas de test présents sur le référentiel de test Squash, puis je réalise le refactoring, et enfin je réimporte les cas de test mis à jour dans Squash.

L’outil propose des connexions avec des outils de test différents, tels que ALM, Squash, Testlink, Zéphir etc. Ceci permet de travailler sur différents référentiels de test de manière à exporter les cas de test vers Orbiter et de les réimporter ensuite, une fois les tests mis à jour.

Figure 2: Interconnectivité de l’outil Orbiter

Fonctionnalités de l’outil :

L’outil propose quatre fonctionnalités principales :

1. L’analyse des suites de tests pour le regroupement des cas de tests

Cette première fonctionnalité permet d’importer des cas de test à partir d’un outil de gestion des tests (par exemple ALM, Squash), de regrouper ces cas de test à l’aide d’algorithmes de regroupement hiérarchique, et de les afficher dans une vue arborescente à l’aide de dendrogrammes. Cette fonctionnalité peut être utilisée pour analyser les similarités et redondances qui existent entre différents tests pour le même niveau et entre différents dossiers, ceci en changeant le niveau de profondeur d’analyse.

• Optimisation et refactoring des cas de test

La deuxième fonctionnalité de refactoring qu’offre Orbiter est l’identification des étapes de cas de test similaires, afin qu’elles puissent être retravaillées pour utiliser la même terminologie, la même formulation, etc. Comme pour le regroupement des cas de test cette analyse peut se faire sur le périmètre des tests choisis ou sur l’ensemble des tests. Le volet  » Automatic Matcher « , en bas de la capture (Figure 1), montre les résultats d’une recherche de fond dans le périmètre de travail actuel pour trouver les dix premiers steps qui pourraient être de bons candidats pour une refonte, parce que plus similaires à un autre step dans le périmètre sélectionné (par défaut, ou sur l’ensemble des steps). La combinaison de l’usage de ces deux fonctionnalités va permettre de corriger les tests et supprimer les redondances à travers l’ensemble des tests du référentiel.

• La visualisation des cas de test et de leurs interactions

Pour un cas test ou un groupe de cas tests sélectionnés, Orbiter peut reconstruire des parcours applicatifs, une visualisation des cas de test sous la forme d’un processus métier montrant les séquences de tous les steps de ces tests.

Ces parcours sont interactifs dans le sens où il est possible de survoler un cas de test spécifique et de voir son cheminement à travers le processus métier. La visualisation est immédiatement mise à jour lorsque les steps sont mis à jour, de sorte que l’utilisateur voit par exemple les steps fusionnés.

• Les métriques pour le suivi du refactoring

Afin de déterminer la progression du refactoring et de l’optimisation du référentiel de test, l’outil fournit des métriques telles que : le nombre de cas de test, le nombre de steps (actions et résultats attendus) au sein de ces tests, et également le nombre de « mots-clés » (toute étape de test utilisée plus d’une fois).

• Les résultats obtenus sur plusieurs projets

J’ai utilisé Orbiter sur une dizaine de suite de tests à reprendre, allant d’une dizaine de cas de tests à plus de 700 cas de tests (voir le tableau ci-dessous).  Les premières expérimentations ont été menées sur des suites de test de taille réduite (10aine de cas de test) pour étudier les fonctionnalités de l’outil. Et ensuite sur des volumes de plus en plus grands pour éprouver l’adaptabilité de l’outil à des référentiels plus larges.

Ces différentes expériences ont été menées sur des suites de test réelles existantes associées à des applications contenant une variété de cas de test de différents niveaux de complexité. Pour permettre une comparaison avec ou sans Orbiter, nous avons évalué le travail manuel qui aurait été nécessaire de façon à mesurer les gains de productivité.

Le tableau suivant présente les résultats du travail de refactoring des tests. Nous avons les colonnes suivantes :

• Le nombre de cas de tests à l’origine étudié, puis la diminution du nombre de cas de test après avoir effectué le refactoring.
• le nombre de steps à l’origine étudié, puis la diminution du nombre de steps après avoir effectué le refactoring.
• le nombre de keywords à l’origine étudié, puis la diminution du nombre de keywords après avoir effectué le refactoring.
• Le temps estimé (en minutes) pour une reprise manuelle suivit du temps de reprise passé avec Orbiter
• L’écart de temps en % entre l’estimation de la reprise manuelle comparée avec la reprise avec Orbiter

L’estimation du temps passé en reprise manuelle est calculée à l’aide d’une formule basée sur le nombre de steps à refactoriser, le temps consacré à la consultation et à la modification de chaque step, la complexité des steps, et l’objectif de refactorisation (un pourcentage déterminé selon les objectifs de la reprise des cas de test)

La diminution du nombre de cas de test sur plusieurs cas est de 0. Ceci s’explique par le fait que mon objectif était souvent d’uniformiser les référentiels, plutôt que de supprimer des tests, ainsi le nombre de cas de test restait le même, mais les tests comportaient moins de steps et étaient plus homogènes.

Dans le cas où l’objectif était de réduire au maximum le nombre de cas de test (expérience 9) j’ai observé que le temps passé avec Orbiter était plus long qu’une reprise manuelle. Dans les cas où l’on vise un refactoring élevé (plus de 80%), il est plus rapide de supprimer les cas de test directement depuis le référentiel que dans Orbiter.

Ces expérimentations ont donné lieu à une diminution moyenne de 14% du nombre de cas de test, 18% du nombre de steps et 28% des keywords. L’outil a offert un gain de productivité non négligeable sur les activités de refactoring avec un gain de 57.49%.

Figure 3 : Résumé des résultats des expérimentations avec Orbiter

Conclusion

La reprise et l’optimisation des cas de tests manuels sont des situations très courantes dans les projets, et souvent assez laborieuses à gérer de façon totalement manuelle. Cela est particulièrement vrai lors de la migration d’un système ou d’une application vers une nouvelle plateforme, ou lors de l’introduction de l’automatisation d’une partie des cas de tests manuels existants.

Mon expérience avec l’outil Orbiter m’a permis d’automatiser une partie des activités de refactoring des étapes et des cas de test afin d’améliorer la maintenabilité des cas de test existants. Les résultats obtenus en termes de qualité du refactoring et de gains de productivité montrent la contribution significative de l’assistance fournie par cet outil par rapport au refactoring sans aucun outil.

Si vous aussi vous voulez découvrir l’outil : http://orbiter.smartesting.com/

A propos de l’auteur: Elodie Bernard

Consultante en test en entreprise, je réalise une thèse sur ce domaine: de la reprise de référentiel de test jusqu’à l’automatisation.

Je suis passionnée par l’univers testing et je suis toujours à la recherche de nouvelles démarches et outils pour faciliter, améliorer et optimiser les activités du test.