Automatisation des tests de migration de données vers Confluence avec une approche BDD

Enregistrement vs. Documentation

Dans la démarche de digitalisation des entreprises, les outils agiles tels que ceux de la suite Atlassian sont des outils incontournables. Cela induit une nouvelle méthode de travail notamment en utilisant le système de ticket de JIRA (pour représenter les éléments unitaires tels que des exigences, des risques, des tests, etc.) une nouvelle méthode de gestion avec des Pages Confluence, des options supplémentaires par rapport aux GED classiques : un système de gestion de versions automatique et des interfaces avec des outils externes… (pour plus de détail n’hésitez pas à consulter notre webinaire sur le sujet https://www.youtube.com/watch?v=vwMy1TRYnuo)

Vue Jira de gestion de workflow

Passer à une gestion documentaire sous Confluence nécessite généralement une étape de migration (depuis une GED ou depuis un système de fichiers), étape cruciale dont il faut s’assurer de la bonne exécution. Le volume important de documents et le nombre de vérifications à faire sur chaque document font que l’automatisation des tests de migration apparaît comme le seul moyen d’atteindre les objectifs de qualité, de fiabilité et d’exhaustivité des tests.

Notre article se concentre principalement sur l’automatisation des tests d’une migration documentaire depuis une GED classique ou un système de fichiers vers Confluence, en utilisant la méthodologie BDD (Behaviour Driven Development) et le plug-in JIRA de gestion de test : Xray

Migration GED vers confluence

BDD (Behaviour Driven Development)

BDD est une méthode de développement agile qui vise à favoriser la collaboration entre les développeurs et les parties prenantes non techniques (experts fonctionnels, testeurs, qualité, etc.) d’un même projet.

Au niveau des tests, c’est une évolution du TDD (Test Driven Development). Le but est de passer du test sous forme de code dans le cas de TDD vers des scénarios compréhensibles par toutes les parties prenantes impliquées dans le projet et non seulement par des développeurs.

TDD vs BDD

“In TDD, I’m not concerned about the output. The only thing needed is to carry out the test in a particular way.”

“In BDD, I don’t mind how you come up with the output, except the output has to be correct under the given condition.”

Pour plus de détail : https://www.youtube.com/watch?v=ZUJe6bhBX2E

Gherkin

Gherkin est le langage le plus couramment utilisé dans les approches BDD. Il permet de spécifier des descriptions de comportement sans avoir besoin d'entrer dans les détails de la mise en œuvre.

Il est notamment utilisé pour décrire des user stories mais aussi des tests, en permettant de définir l'objectif que l'utilisateur souhaite atteindre, les étapes qu'il entreprendra et la manière dont le produit doit répondre.

Le langage Gherkin

Behave

Behave est un framework de test en langage Python. Il permet de développer des tests

automatisés en se basant sur le langage Gherkin. Il est utilisé pour traduire en code les étapes d’un test rédigé en langage Gherkin.

Implémentation des étapes Gherkin

Notre cas d’utilisation

Il s’agit de tester de manière automatique une migration d’un fichier word vers une page Confluence, réalisée en utilisant un convertisseur de fichiers Word vers des pages Confluence. Dans notre cas de test, on veut s’assurer que les articles Confluences créés ont la même arborescence de titres que les fichiers Word depuis lesquels ils ont été créés et importer les résultats de la comparaison qui sont sous forme de rapports JSON dans Jira/Xray. Ces rapports contiennent aussi des pièces jointes comme preuves d’exécution, qui sont dans notre cas des fichiers .txt, un premier contenant la structure du fichier d’origine, un deuxième la structure de la page Confluence et un troisième la différence entre les deux structures.

Illustration technique de l’implémentation des tests de la migration

Pourquoi nous avons opté pour un test automatisé ?

La quantité de données à tester

Un test automatique permet de réduire le temps de test dans le cas d’une migration. Une migration d’une GED c’est souvent une migration de plusieurs centaines de fichiers ce qui n’est pas aisé à tester de manière exhaustive et nécessite des ressources humaines dédiées. Avec un test automatisé le coût le plus important, c’est le temps d’implémentation du test sachant que ce coût peut être facilement amorti avec le nombre de fichiers à tester et l’utilisation sur différents environnements (bac à sable, recette, production, etc.) vu que le code est réutilisable.

La précision et fiabilité des tests

Les tests automatisés s’appuient principalement sur du code qui est rédigé effectivement par un humain, mais qui a subi des méthodes de sécurisation de code (revue de code, validation). La précision des tests automatisés est supérieure à la précision d’un testeur manuel ; notamment dans notre cas d’exemple un testeur est capable d’intervertir deux niveaux de titre, de comparer des titres qui ne sont pas au même niveau, oublier un titre, etc.

La remontée des résultats d’exécution dans Xray

Dans notre cas d’exemple on utilise le module Xray/Behave pour remonter les preuves d’exécution, et cela, d’une manière automatique.

Tout ingénieur de test sait comme il est fastidieux d'attacher les preuves d'exécutions dans les résultats des tests en prenant des captures d'écran, en allant chercher des fichiers de logs..., de récupérer ces fichiers en local et puis les joindre aux exécutions de test dans la bonne étape de test. Dans le cas de notre exemple de migration, pour chaque fichier Word migré sur confluence on a 3 fichiers de preuves d'exécution attachés au test exécution. Vous pouvez imaginer la charge de travail nécessaire à réaliser cela manuellement, et donc les ressources que le test automatique nous a fait gagner.

Exemple de preuve d’exécution

La gestion des bugs et des évolutions

La gestion des tests dans le cas d’une évolution du produit est beaucoup plus simple, une mise à jour du test est suffisante pour que le test soit effectif, et une analyse des bugs simplifiée, car on dispose d’un scénario (le test) pour reproduire le bug et les traces nécessaires pour pouvoir l’analyser.

Conclusion

Dans cet article, nous avons abordé différents sujets :

• Réduire l’écart entre le métier et les techniques avec une approche BDD et le langage Gherkin. En effet, qui de mieux que le métier pour définir les règles de migrations fonctionnelles.

• Une approche issue des meilleurs pratiques, la FDA Food and Drug Administration soutient et encourage l'utilisation de solutions automatisées et informatiques.

• Pas d'obstacle réglementaire

• Une transition douce vers l’automatisation des tests qui s’inscrit dans la démarche globale de la Continuous Integration et Continuous Delivery

• Une opportunité de capitaliser sur les tests d'intégration

• Un chemin vers la validation continue