L’agilité, de par le découpage des grosses applications et les livraisons régulières (les sprints), nécessite de revoir la façon d’envisager les tests de charge et d’appliquer la méthodologie TDC.
En cycle en V, les applications sont vues comme un ensemble monolithique, les TDC permettent donc de qualifier l’ensemble du SI en fin de version (modulo quelques patchs).
Il est donc possible de modéliser une campagne de TDC sur une application en cycle en V de la façon suivante :
Dès que l’application est découpée en module ou en micro service, chacun développé par une équipe différente et fortement autonome, il est nécessaire de revoir fortement la façon de gérer l’aspect performance.
L’agilité ayant pour but de diminuer drastiquement le TTM, il est nécessaire de découvrir au plus tôt les problèmes tout en continuant à assurer des tests bout en bout de l’application (et donc de valider la cohérence de l’ensemble).
Au même titre que pour le développement d’une voiture de course, il n’est pas nécessaire d’attendre d’avoir toutes les pièces (moteur/châssis/freins/aéro) pour commencer à tester le moteur.
Il est tout à fait possible de tester un moteur sur un banc de test, l’intégrer avec la boite de vitesse, de l’intégrer sur une ancienne voiture et finalement de le mettre dans la voiture en version finale.
En fonction de la complexité de l’application, il va donc être nécessaire de découper les tests en plusieurs étapes pour traiter chacun des sujets séparément.
Chaque étape doit apporter quelque chose afin de ne pas impacter inutilement le TTM, plus on avance, moins il devrait y avoir d’itération de test.
Chaque étape doit franchir un niveau de maturité sur un sujet pour passer à l’étape suivante de même que les étapes avancées (prod comprise) doivent permettre d’apprendre à enrichir pour rendre plus pertinent les étapes précédentes.
Il est alors possible de modéliser une méthodologie de test en environnement modulaires/micro-services comme ceci :
Le nombre d’étape dépend bien évidemment de la complexité du SI, les 4 étapes ne sont présents qu’à titre d’exemple.
La méthodologie évoluant, l’organisation d’un service de TDC et certains rôles TDC vont forcément évoluer.
Actuellement la structure la plus courante pour adresser les campagnes de TDC sont « l’équipe » ou « le centre de service » de tests de charge :
Comme une partie des TDC est directement à la charge de l’équipe devops, la structure de base va forcément évoluer :
En effet les membres des équipes devops deviennent partie prenante des tests bouchonnés.
Le rôle des experts TDC « historiques » est alors de garantir que la cohérence (communication, données, volumétrie d’appel) et la robustesse transverse (et plus particulièrement l’aspect systémique), alors que les devops sont plus orienté performance de leur module.
Il se pose alors 2 problématiques :
1 Comment assurer la monté en compétence des membres des équipes devops en matière de TDC :
En termes de ressource, il est plus facile de trouver un devops intéressé par les problématiques de performances qu’un expert TDC à mettre dans toutes les équipes devops.
2 Comment assurer l’homogénéité, la maturité et l’enrichissement entre toutes les étapes des TDC :
Il s’agit d’un nouveau rôle, avec une forte compétence en TDC.
En binôme avec le responsable TDC, son rôle est :
– d’évangéliser les bonnes pratiques des tests de charge,
– d’assurer l’homogénéité entre les différentes étapes de test via la validation de maturité des tests au niveau des modules et l’enrichissement des tests afin d’être pertinent dans l’étape la plus en amont possible.
Le Coach TDC et le responsable TDC sont alors les référents de la performance transverse du SI.
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
