La taverne du testeur

Les Tests de charges dans un environnement Agile Modulaire/Micro Service

 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 :

0

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 :

2

Le nombre d’étape dépend bien évidemment de la complexité du SI, les 4 étapes ne sont présents qu’à titre d’exemple.

3

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 :

4.jpg

Comme une partie des TDC est directement à la charge de l’équipe devops, la structure de base va forcément évoluer :

5

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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Automatisation

Robot Framework : le couteau-suisse de l’automatisation

Pour automatiser des tests, il est nécessaire d’utiliser des outils adaptés. Partir la « fleur au fusil » avec pour seule arme un langage de programmation n’est pas suffisant, au risque de devoir réinventer la roue. Nous allons voir ensemble ici les caractéristiques qui font de Robot Framework un bon candidat pour

Lire la suite »
Agilité

9 : Avantages de BML

Les tableaux présentés jusqu’à présent montrent que chaque affirmation BML peut faire l’objet d’une cellule dans un tableau. On se retrouve sous la forme de l’ATDD “automatisée” (avec un générateur automatique des scénarios de test).  Exemple : Quand X Y Alors Z direction(par défaut étape suivante) Etape E1 – RG1 X=0

Lire la suite »
culture générale

Les niveaux de test

Pour avoir un exemple imagé sur les niveaux de test je vous invite à lire cet article complémentaire. Introduction : Il existe d’après ISTQB (International Software Testing Qualifications Board), 4 différents niveaux de tests. Comme je l’ai déjà expliqué plusieurs fois dans mes articles précédents le test ne se résume pas

Lire la suite »