Avec l’avènement des méthodes agiles, l’organisation pour continuer à assurer la qualité technique doit évoluer (sujet évoqué dans un article précédent : lien ).
L’application de la méthodologie de test de charge évolue aussi.
Le fait de tester régulièrement un SI permet une forme d’historisation des résultats.
Les objectifs d’évolution de comportement (méthode incrémentale – SLA dynamique) deviennent prépondérant d’une version à l’autre et complémentaire avec les vérifications standards des SLA (SLA statique).
Nous entrons alors dans le domaine de l’historisation des évolutions de comportement, mais il faut bien identifier les ruptures rendant ces comparaisons caduques:
– Quand la comparaison a-t-elle un sens (Non-régression)?
– Quand sommes-nous dans un cas de rupture et donc comparaison impossible (extension de périmètre, étape intermédiaire et/ou création d’une nouvelle référence)?
Reprenons la base de la définition d’une campagne :
Définition d’une campagne :
- Périmètre technique (architecture, socle, version)
- Périmètre fonctionnel (cas de test/données) et volumétrie
- Objectifs de résultat (SLA et anticipation d’une évolution)
- Planning
- Mode d’activation des nouveautés (embarqué, activable/désactivable à chaud…)
Ce qui permet de définir une campagne de la manière suivante :
Si je reprends l’organisation nécessaire aux tests de charges en environnement modulaires/micro-services :
En environnement full-bouchonné (perf) pour un test de composant/micro-service, il y a un modèle de charge pour la non-régression (historisation), et un modèle de charge avec extension de périmètre. Une fois la maturité suffisante sur le test avec l’extension de périmètre, ce test devient la nouvelle référence. L’exécution des tests étant très régulier (plusieurs fois par semaine), il ne devrait pas être nécessaire de traiter plus de deux modèles d’utilisation.
Les ruptures interviennent régulièrement et correspondent à chaque bascule d’une extension en référence.
Dans un environnement plus proche de la production (traditionnellement la pré-prod) et bout-en-bout, les tests sont moins régulier (une campagne par mois), il y a potentiellement plus de sujets.
La référence change à chaque campagne et correspond au dernier périmètre ayant atteint la maturité nécessaire (dans le cas du schéma ci-dessus, la 2eme extension de périmètre).
Il est néanmoins indispensable que le comportement observé (sollicitation front et interaction entre les modules/micro-services) lors des tests bout-en-bout ou en production alimente en permanence les tests plus isolés afin que ceux-ci soit toujours cohérent avec l’utilisation réelle.
Si cette étape d’apprentissage permanent ne fonctionne pas, les étapes de tests ne sont plus complémentaires les uns avec les autres (périmètre divergeant) et aussi avec la production. Le risque de découverte tardive des problèmes de charge devient important, impactant soit la qualité de la production, soit le TTM.
Le rôle du coach TDC est donc prépondérant pour assurer la cohérence et la complémentarité des tests.
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
