Aujourd’hui, nous sommes capables de tester les applications en continue. Les tests fonctionnels et les tests unitaires font déjà partie intégrante de l’intégration continue mais même avec la multiplication des environnements (développement, qualification, pré-production) nous en oublions qu’il est possible d’y intégrer les tests de performances, les tests de charges, et le monitoring des performances au sein du cycle de vie applicatif.

Introduction

Aujourd’hui on nous parle de DevOps, de Paas, d’IaC, d’architecture cloud, et autres techniques novatrices. Mais posons une question : “Vous utilisez toutes ces techniques, très bien, si 500 utilisateurs se connectent dans une heure l’application va-t-elle tenir ? Combien cela va vous coûter si elle tombe ? Combien cela va vous coûter si elle tient ?”. Que cela soit une surconsommation de ressources clouds, une indisponibilité de l’application ou des utilisateurs insatisfait, le risque de surcoût est élevé.
Une application possède seulement quelques étapes dans son cycle de vie : conception, implémentation, tests, et mise en production. Les tests unitaires et fonctionnels font partie intégrante de ce cycle de vie mais ne permettent pas de déceler tous les problèmes, ils sont indispensable mais pas suffisant.

Pourquoi tous les problèmes ne sont pas détectés ?

Parce que certains problèmes, on le sait, n’apparaissent qu’à partir du moment où le système atteint une certaine charge. Par exemple il vous sera difficile de savoir que vous avez une fuite mémoire ou un problème de garbage collection avec l’activité des 15 développeurs travaillant sur l’application.

Pourquoi nous n’intégrons pas ces tests ?

Parce que la performance est un secteur de niche. Sorti d’école d’ingénieur, je connais beaucoup d’autres personnes ayant fait ce type d’école ou d’autres formations en informatique. Le fait est là : Aucune des écoles que je connais ne parlent d’autres types de tests que les tests fonctionnels et unitaires. De facto, peu de gens s’orientent vers ce secteur à la sortie de l’école, donc il y a peu d’experts sur le marché, donc les experts coûtent cher, donc beaucoup de petites entreprises ne font tout simplement pas ces tests alors qu’elles le pourraient.

Coûts, Durées, Risques

Vous lancez une campagne de tests de performances facturée à la journée à un sous-traitant. Des problèmes se posent :

• Combien de temps la campagne va prendre ?
  • Combien de temps vos environnements risquent d’être immobilisés pour les tests ?
  • Combien de temps allez vous mobiliser vos équipes pour qu’elles fournissent aux testeurs les données dont ils ont besoin ?
  • Quel est le retard potentiel que peut subir la mise en production ?
• Quel sera le coût de la campagne ?
  • Combien de jours vont être facturés par l’entreprise de prestation ? (coûts humains)
  • Les licenses des outils utilisés devront être acquises pour combien de temps ? (coûts matériels)
• Est-ce qu’on peut se fier aux résultats ?
  • Est-ce que la campagne a été correctement menée ?
  • Est-ce que la couverture des tests a été optimale ?

Pour avoir participé à plusieurs campagnes de tests : il y a toujours un risque pour que la campagne s’allonge. Certaines applications sont tout simplement un enfer à tester car mal développée, mal conçue, ou trop instable.
Cependant, les tests étant indispensables, votre campagne ne fera que s’allonger, les coûts de la prestation augmenter, et la date de mise en production repoussée. C’est pour cela qu’il faut savoir plusieurs choses :

• Quels sont les problèmes les plus important à tester/résoudre ? Quels sont les problèmes que vous auriez pu anticiper ?
• Quand êtes vous prêts à lancer votre campagne de test ?
• Comment tester les performances de VOTRE application ?

Tout cela, vous le saurez en intégrant les tests de performances dès votre environnement de développement et jusqu’à la plateforme de qualification :

• Vous saurez quoi tester car les problèmes simples à régler l’auront été en amont de la campagne de test par vos développeurs et/ou vos opérationnels.
• Vous saurez que vous pouvez tester quand vos tests de charges ne seront pas victime de l’instabilité de votre application.
• Vous saurez comment tester, parce qu’une partie du travail est déjà faites.

En termes de maîtrise des coûts, cette approche permettrait une meilleure gestion des coûts humains et matériels grâce à des estimations plus précise de la durée et de la difficulté des différentes tâches. De cette façon, vous évitez les retards, vous évitez le surcoût, et vous évitez les doutes.

La possibilité

Être innovant, ce n’est pas forcément faire quelque chose parce qu’on en a besoin. Parfois c’est faire quelque chose simplement parce qu’on en a la possibilité. Aujourd’hui on automatise le déploiement d’infrastructures complètes ou de containers applicatifs alors que les tests de charges sont toujours exécutés à la main. Pourquoi ne pas lancer un test de charge automatiquement à chaque déploiement d’une infrastructure sur une plateforme de qualification ? Est-ce mieux d’attendre 1 jour, 1 semaine ou 1 mois pour déceler un problème qui entrainera une régression de l’application ?
En aggrégeant les outils d’aujourdhui, vous pouvez déployer vos machines de tests en même temps que votre environnement de qualification et lancer vos tests de charges dans la foulée.

Conclusion

Demandez à votre DevOps combien de temps cela va lui prendre d’intégrer une nouvelle étape dans l’intégration continue de votre application.
Demandez à vos développeurs combien de temps cela leur prendrait de faire des scripts avec JMeter ou Gatling.
Demandez à vos opérationnels si il existe des plages horaires où votre environnement de qualification est disponible.
Vous mettrez cela en place.
À la fin de votre prochaine campagne de test : comparez le coût et la durée de la campagne avec la durée des précédentes. Votre équipe IT ne mérite t’elle pas une invitation au restaurant et un jour de congé ?