Interview de Bruno Audoux, responsable de l’innovation chez WAPSI
Bonjour Bruno, si je suis là aujourd’hui c’est parce que vous me dites que deux mondes se rejoignent, l’automatisation et les tests de performances.
Oui en effet, Le premier sert usuellement aux déploiements et aux tests de non-régression, et le second a pour fonction la validation d’une application sous la charge.
Alors pourquoi nous n’avons pas automatisé les tests de performance avant ?
Déjà car cela n’était pas nécessaire, les tests de performances étaient réalisés juste avant une mise en production, il était rare qu’on ait besoin de faire des campagnes régulières pendant l’année.
Et donc qu’est ce qui a changé ?
L’AGILE, un mot magique qui touche tout le monde aujourd’hui dans le monde de l’IT, les développeurs ont d’abord été concernés mais ce monde agile ne peut fonctionner correctement que s’il est en synergie avec d’autres sphères agiles. Le monde des tests a donc pris un peu de temps pour proposer des méthodologies de travail adaptées à ce type de livraison rapide et régulière.
Et quels sont les grandes nouveautés ou changements ?
Le principal changement c’est le rythme de livraison : un sprint c’est classiquement 3 semaines, et produire une recette complète toutes les 3 semaines c’est un vrai défi ; cela demande une énorme coordination en amont sur les périmètres de test, mais aussi un partage d’information plus clair sur les résultats de test, sans parler des mises à jour des scripts de test bien sûr.
C’est là qu’intervient l’automatisation ?
Oui et non, si nous avons initialement mis en place des outils d’automatisation pour les tests de sprint, on s’aperçoit que se limiter à un test par sprint c’est de la perte de ressource et de temps.
On peut faire beaucoup mieux.
En fait à partir du moment où l’on met en place une chaine de tests automatisés, celle-ci est encore plus utile sur des tests quotidiens. Elle peut devenir un vrai outil de test de non-régression sur les indicateurs de performance. Ses résultats s’adressent directement aux développeurs qui peuvent modifier durant le sprint leur code et l’optimiser avant la livraison du sprint.
Concrètement comment cela fonctionne ?
Au niveau des outils, nous reprenons les outils du marché, pour lesquels les éditeurs ont dû beaucoup changer la manière de fonctionner, il fallait que ces outils puissent être pilotés par d’autres programmes et produisent des rapports automatisés. Un outil comme Gatling est issu de cette mouvance et est parfaitement adapté au pilotage externe, mais Neoload et Loadrunner ont dû ajouter des points d’entrée comme le AsCode ou les API pour être pilotable.
De plus ces outils ont appris à utiliser du code sur des repository comme Gillab ce qui les rend plus flexible.
Je n’ai pas encore compris.
C’est normal je n’ai pas encore fini.
Donc à ce moment-là on les pilote par des orchestrateurs, Jenkins étant assez fiable pour ce type de travaux, nos outils finissent dans des Pipelines qui montent les applis de test, chargent les scripts et les jeux de données, réalisent des tirs courts (5 à 30 mins) et envoient les résultats dans un repository autorisant les comparatifs. En faisant des tirs toutes les nuits sur une plateforme d’intégration, les développeurs peuvent vérifier la qualité de leur code bien avant le passage en pré-production.
Donc les développeurs peuvent vérifier qu’il n’y a pas de dégradation sur leur livraison ?
C’est exact, vient la problématique de comparer les résultats ; les outils de reporting sont tout juste sortie d’usine sur ce type de fonctionnalité. D’un côté, Loadrunner 2020 propose le module TrendReport, Neotys propose le NeoloadWeb qui fait des courbes de tendance. Mais dans les deux cas, ces outils ne font que présenter les résultats, ils ne sont pas conçus pour faire des alertes.
Alors comment gérer les alertes ?
On retourne dans Jenkins, on configure des scripts d’analyse et on pousse nos alertes vers des mails ou des Dashboards. Les éditeurs ne devraient pas tarder à proposer des fonctionnalités là-dessus en accord avec leurs fonctions de SLA. C’est une question de temps.
Où est le problème de ce type d’outil de test automatisé ?
Il y en a deux. Le premier est la mise à jour des scripts, même si les éditeurs proposent des fonctionnalités de mise à jour automatisées qui fonctionnent, certains framework sont trop complexe et l’intervention humaine est indispensable. L’autre, c’est les changements de périmètres de test, par principe dans l’AGILE ont peut retirer une fonction d’un site, et donc il n’est plus nécessaire de le tester, cela doit se faire manuellement aussi et les comparatifs entre deux tirs qui n’ont pas les mêmes scripts nécessitent aussi de l’intervention d’expert.
Combien de temps pour déployer une infrastructure de test de performance automatisé ?
C’est rapide, on s’appuie sur la technologie microservice (docker). Donc quelques jours pour la partie technique, le plus long étant de faire un cadrage de qualité et des scripts de démarrage. Pour les scripts de maintenance et d’alerte, nous avons déjà des templates. En une semaine le client peut être équipé de son moteur, il ne reste plus qu’à former ses équipes.
Un dernier mot pour nos lecteurs ?
Oui j’ai précisé que ce type d’outil apportait des informations aux développeurs mais c’est beaucoup plus vaste que cela. S’il est monté sur une préprod ou une production, il apporte aussi des informations de fonctionnement à l’équipe métier, et aux équipes de support. Les possibilités sont encore vastes et ne demandent qu’à être explorées.
Merci !
Septembre 2020, interview réalisé avec un masque FFP2.
