Automatisation des tests de questionnaires
L’un de nos objectifs chez BOTdesign est de récolter et de classifier les données patient afin de restituer aux professionnels de santé un compte-rendu clair et efficace de l’état de santé du patient.
Cette récolte d’informations se fait sous la forme de robots conversationnels qui vont poser des questions aux patients et récupérer les réponses de ces derniers. En fonction des réponses, les robots vont affiner certains sujets et en alléger d’autres. Au final, le nombre de combinatoires est donc exponentiel. Tester toutes ces combinatoires chaque fois qu’un élément d’un questionnaire ou du moteur d’exécution évolue est vite devenu un travail fastidieux et chronophage.
C’est pourquoi nous avons réfléchi à une solution simple pour automatiser les tests de ces questionnaires
Analyse du besoin
L’outil ou le processus que nous allons mettre en place doit respecter les besoins suivants :
Fournir des preuves
En tant que dispositif médical, chaque fois que nous faisons évoluer la solution MAX, nous devons conserver des “preuves” des tests que nous avons effectués. Le plus souvent, il s’agit de capture d’écran ; ainsi, en cas d’audit de qualité, nous pouvons présenter les tests effectués pour chaque changement de version.Rédaction possible par des non-développeurs
Chez BOTdesign, c’est l’équipe métier qui effectue le paramétrage des robots. Cette dernière doit rester autonome quant à la rédaction de tests correspondant au paramétrage.Exécution automatique ou manuelle
Les tests doivent se lancer de manière automatique lorsqu’une nouvelle version d’un questionnaire médical est déployée, mais aussi de manière manuelle si l’on souhaite rejouer l’ensemble des scénarios.Maintenable
L’outil ou le processus doit rester maintenable. C’est-à-dire demander moins de temps de développement que les éléments qu’il teste. On a tous connu les tests de composants front qui demande plus de temps pour refaire le test que ce qu’il en a fallu pour faire la fonctionnalité.
Fort de tous ces besoins, notre choix s’est porté sur l’outil Playwright.
Mise en place de l'outil
Nous avons entendu parler de Playwright à la conférence Devoxx où nous étions présents cette année pour la première fois.
L’outil semblait correspondre à notre besoin et après quelques recherches, il s’intègre très bien avec Cucumber qui répondrait alors à la problématique d’accessibilité à des non-développeurs.
Premiers tests et validation de la faisabilité
Après quelques jours d’exploration et de test, Raphael Pech , notre stagiaire Fullstack, a été en mesure de dérouler de manière automatique un questionnaire de bot.
La démonstration de l’outil et de ce que Raphael Pech a pu faire en quelques jours nous a convaincus. Playwright est simple d’utilisation et il est capable de générer des captures d’écran de l’application en train de dérouler et est facilement automatisable. Autre fonctionnalité intéressante, il peut exécuter les tests dans différentes configurations clientes, par exemple avec Firefox, Chrome ou Safari, ou avec des résolutions mobile pour s’assurer que tous les éléments apparaissent bien à l’écran.
Intégration avec Cucumber
Cucumber est un outil permettant d’écrire des scénarios de test de manière intelligible pour un humain. C’est-à-dire autrement qu’avec un langage de programmation. Cela va permettre à notre équipe métier de décrire des scénarios de test pour les questionnaires de bots sans avoir de connaissances en programmation.
Un scénario de test est appelé une spécification; il est représenté par un fichier .feature qui va contenir des fonctionnalités qui contiennent à leur tour les étapes du test. Un fichier de spécification ressemble à ça :
# language: fr
Fonctionnalité: 'Test du questionnaire Oncogériatrie'
Test du déroulement d'un questionnaire Oncogériatrie sur MAX
@Notice
Scénario: oncogeriatrie
Soit je me connecte à MAX en tant que 'patient'
Et je choisis le questionnaire "Oncogériatrie"
Quand je démarre le questionnaire avec le bouton "Cliquez ici"
Et je réponds "65"
Et je réponds "157"
Et je clique sur le choix "Oui"
Et je clique sur le choix "Oui"
Et je clique sur le choix "Non"
Et je clique sur le choix "Non"
Et je clique sur le choix exact "Oui - Continuer"
Et je clique sur le choix "Non"
Et je clique sur le choix "Oui"
Et je clique sur le choix "Moyen"
Et je clique sur le choix "Non"
Et je passe la question
Et je clique sur le choix "Le patient lui-même"
Et je clique sur le choix "Oui - Continuer"
Et je clique sur le choix "8"
Et je clique sur le choix "Terminer"
Alors le questionnaire est terminé
On commence par déclarer la langue dans laquelle est rédigé la spécification (l’anglais est aussi possible). Puis on explicite le nom, la description de la spec et le nom du scénario; ici, on déroule un questionnaire d’Oncogériatrie.
Puis viennent toutes les étapes du test. Chaque étape est précédée d’un mot-clé :
Soit, pour décrire les données d’entrée
Quand, pour décrire les actions à faire pour le test
Alors, pour le résultat attendu
C’est simple à lire et à comprendre ainsi qu’à produire.
Coté technique, cela demande d’écrire des fonctions correspondantes à chaque action possible qui vont, grâce à Playwright, exécuter l’action sur l’interface de MAX.
Automatisation
Afin d’automatiser le processus, un pipeline Gitlab est créé dans le projet pour exécuter les tests. À chaque fois qu’une modification sur ce projet est effectuée, les tests sont rejoués. De même, le pipeline de déploiement de notre environnement de validation a été modifié et chaque fois qu’un déploiement de l’environnement de validation est fait, il lance le pipeline de test des scénarios. Ce qui nous garantit que tous les changements qui arriveront sur la production ne vont pas casser nos configurations de questionnaires.
De plus, les pipelines Gitlab stockent le résultat des tests, la liste des captures d’écran et le détail des actions effectuées. Cela nous permet de comprendre ce qu’il s’est passé quand un test échoue et nous garantit une traçabilité maximale sur nos tests.
Conclusion
Au final, le projet tourne actuellement sur nos environnements de qualification et nous prévoyons de l’inclure très prochainement sur nos environnements de production.
Il aura fallu 120h de travail en comptant la montée en compétences sur Playwright et Cucumber pour réaliser ce projet.
Les métiers n’auront plus à dérouler les questionnaires à la main pendant leur paramétrage ou après chaque modification de l’application.
On gagné un archivage des rapports de test avec des captures d’écran.
Il ne faut plus que 45s pour dérouler les questionnaires les plus complexes quand il faut plus de 5mn à un métier connaissant le questionnaire.
Mission accomplie !
Rédaction : Frédéric Combes et Raphaël Pech