Gatling ouvre sur une scène d'équipe de performance centrale : la version candidate est prête, quelqu'un demande si elle a passé un test de charge, et le prochain créneau est dans deux semaines. Gatling décrit les coûts de ce modèle : un test qui devient un événement planifié, un retour tardif et chez la mauvaise personne, une file d'attente, des scénarios qui reflètent le trafic du trimestre dernier. Il cite le test d'un composant de Healthcare.gov arrivé à 1 100 utilisateurs avant que les temps de réponse ne deviennent trop élevés, pour un objectif de 10 000, la veille du lancement.
« Chaque développeur teste » ne le convainc pas non plus : une étude de 111 projets Java libres, citée, donne 246 lignes de test de performance contre 3 980 de tests fonctionnels pour le projet médian. Sa proposition : les équipes possèdent objectifs, scénarios (versionnés avec leur code) et corrections ; la plateforme possède injecteurs, environnements, standards et tests de capacité. Le modèle, précise-t-il, ne convient ni aux petites équipes, ni aux systèmes très couplés, ni sans CI/CD ni observabilité.
Ce que ça change pour un testeur de performance
Le texte est signé par un éditeur qui vend la plateforme décrite, et ses exemples clients sont des arguments commerciaux. La répartition des rôles reste plausible, mais les preuves sont des exemples choisis par l'éditeur, pas une étude comparative. Si vous êtes spécialiste, la place qu'il vous assigne est celle de celui qui bâtit la voie commune plutôt que de celui qui exécute chaque campagne. Vérifiez si votre contexte remplit les conditions qu'il pose lui-même.
Les études et les cas cités ne sont pas rejoués ici. « Moving the test is not the same as moving the ownership », écrit l'auteur.
Rédigé avec l’aide d’une IA, relu et validé par Philippe Naveau.