Des tests en prod ?

Introduction

On nous a toujours appris que les tests en production c’était mal, qu’il fallait un environnement dédié pour les tests capable de simuler la production afin de détecter les problèmes en amont et de tester tôt. Les environnements de test font d’ailleurs parti des critères nécessaires selon TMMI afin d’avoir un processus de test discipliné (la base de la professionnalisation).

Si ces postulats sont présents c’est pour une bonne raison… néanmoins on entend de plus en plus parler de tests en production, notamment avec l’émergence du Shift right.

Pour quoi entendons-nous parler de ces tests qui peuvent paraître contre-nature ? Quel serait leur rôle ? Comment les mettre en place ? Ou encore, quels types de tests en productions existent déjà ?

Je vais essayer de vous faire un résumé de tout cela dans cet article!

Pourquoi des tests en production ?

Le principal but des tests en production est le même que celui des tests hors production: détecter des défauts… L’utilisation de tests en production est donc explicable de par une nécessité de connaître l’état de la production et d’éviter des effets dominos amenant au crash de cette dernière ou d’une de ses fonctionnalités.

Je vois les tests en production comme une potentielle partie de la solution à au moins 2 problématiques liées au développement de logiciel moderne:

• La complexité des environnements

Les environnements sont de plus en plus complexes (nombre de partenaires, de terminaux, d’utilisateurs…), massifs (nombre de serveurs ou volume des données) et en mouvement (modifications du logiciel ou de ses partenaires, nouveaux terminaux…). Réussir à simuler efficacement un environnement, dans son ensemble, est une utopie. Les tests exhaustifs sont impossible, la copie parfaite d’un environnement de production le devient également! Le seul vrai environnement ressemblant parfaitement à la production se retrouve être la production elle-même.

A cela on peut également ajouter maintenant la nécessité d’anonymiser des données ou d’en utiliser des fictives ce qui rend encore plus complexe la gestion de gros volumes représentatifs.

• La nécessité d’aller vite

Tout va plus vite dans le monde logiciel actuel. Là où il y avait 2 déploiements (« Mise en production ») annuels il est maintenant fréquent d’avoir 1 déploiement toutes les 2 semaines. J’ai moi même travaillé sur des produits où nous livrions plusieurs fois par semaine… et certaines entreprises en sont à plusieurs livraisons par heure! La tendance n’est pas à un ralentissement alors que les tests restent à exécuter!

La tentation de faire une partie des tests en production devient alors très grande.

Quel rôle pour les tests en production ?

Les tests en production peuvent avoir de nombreux rôles (autant que ce que notre imagination peut trouver). On peut par exemple penser à:

• Tester plusieurs versions d’un produit pour savoir laquelle est le plus appréciée

Ce type de test existait d’ailleurs déjà bien avant le logiciel en 1920 avec de l’A/B testing.

• Détecter rapidement des anomalies en production

Il y a et aura toujours des anomalies en production. L’idéal est d’en avoir conscience avant les utilisateurs. Des sondes, des mesures et du monitoring peuvent permettre de trouver des anomalies avant qu’elles ne gênent les utilisateurs.

• Trouver de potentielles améliorations

En suivant les parcours utilisateurs on peut voir quels sont les freins ou gênes qu’ils rencontrent et alors proposer/imaginer des améliorations sur ces points.

• S’assurer que la production fonctionne toujours

C’est des tests de vie. La production se doit d’être utilisable. Dans le cas où elle tombe il faut s’en apercevoir le plus vite possible afin de rétablir son fonctionnement.

• Tester la robustesse des applications

En testant les limites de la production ou des serveurs en production.

• Avoir l’avis des utilisateurs

A travers des campagnes de crowdtesting ou de bêta test

Il faut néanmoins garder à l’esprit que tout comme les tests exploratoires, les tests en production doivent faire partie d’un ensemble. Le constat de l’introduction persiste, les tests en production ne remplace pas les autres tests, il sont là en complément!

Comment mettre en place ces tests ?

C’est là tout le problème! Les tests en production sont des tests complexes à mettre en place car il ne faut pas gêner ses utilisateurs! Ce n’est pas très grave de faire tomber un environnement de test, ça l’est beaucoup plus quand on fait tomber la production… ou que l’on se retrouver à diviser par 10 le coût des articles en vente sur son site à cause d’une erreur de manipulation!

Pour mettre en place ces tests ils faut donc y aller par étape et commencer par des tests peu intrusifs ou des déploiements permettant de conserver le service (ce qui permet ici de gagner en disponibilité de service!). Il faut également faire appel à des personnes ayant les connaissance et compétences de ce type de test, des outils utilisés et de l’environnement technique de production.

Vous l’aurez compris tout cela fait partie d’une stratégie… je dirais même pour être plus précis, que tout cela fait partie du plan de test maître lié à notre produit/logiciel.

Tester en production ne s’improvise pas… et on ne teste pas seulement en production.

Là encore, je ne le répéterai jamais assez, tous les tests effectués hors production restent primordiaux. Ils sont un filet permettant d’avoir une production saine. Les tests en production sont là pour capturer les anomalies que le filets des tests précédents a laissé passé. C’est un peu comme le modèle en tranches d’emmental auquel on ajoute une tranche, celle des tests en production.

Quelques exemples de tests en production ?

Il existe de nombreuses techniques de tests en production. Il y a par exemple:

• Le Crowdtesting: dans le cas de test de nombreux produit, les crowdtesteurs sont amenés à tester directement sur le logiciel en production… ce qui peut poser des problèmes sur le paiement.
• Les bêta test: qui sont par essence sur les environnements des utilisateurs donc en production
• Les tests automatisés sur la production: qu’on peut voir comme des tests de vie sur des parcours utilisateurs. Cela permet de détecter très tôt si l’environnement de production est KO ou s’il commence à avoir des problèmes de performance. Cela peut également se faire avec des « sondes ».
• De l’A/B testing: pour déterminer quelle version (par exemple d’un écran pour le marketing) est le plus efficace.
• Du Blue/Green deployment: certains serveurs sont cachés, mis à jour puis progressivement ajoutés à la ferme de production. L’intérêt ici est de déployer une nouvelle version sans couper le service mais aussi de manière progressive pour ne pas impacter d’un coup tous les utilisateurs (on peut également coupler cette technique avec du suivi des notes, logs ou crashs applicatifs liés à la nouvelle version). Le « Canary release » et le « Dark Launch » peuvent s’apparenter à du blue/Green deployment
• Des tests de performances en production: ou sur des serveurs de production. L’idée est de connaître les vraies performances de la production
• Du chaos engineering: avec des robots venant aléatoirement tuer des instances afin de tester la robustesse et la redondance de notre production
• Du « Bug Bounty« : avec l’appel à des personnes extérieurs (comme des hackers) pour trouver des anomalies / failles et être rétribué en conséquence.

Conclusion

Les tests en production sont un nouvel outil avec lequel les testeurs vont devoir compter. Le potentiel et l’intérêt sont grands, il faut néanmoins rester très vigilant de par le fait que l’on impacte potentiellement directement la production et donc les utilisateurs. Il faut dès lors garder à l’esprit que les tests hors production doivent continuer à être aussi efficace voir plus grâce à ce que l’on connaît de la production!

Pour réussir cela il faut intégrer ces tests de manière progressive, travailler avec des outils adaptés et des personnes ayant les compétences liées aux environnements de production mais aussi prendre en compte ces tests dans notre plan de test.

Si le sujet vous intéresse je vous conseille vivement cette excellente conférence.

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

N’hésitez pas à faire vos propres retours d’expérience en commentaire.