L'une des idées reçues les plus répandues en tests de performance est qu'ils ne peuvent se faire qu'en fin de projet, sur un environnement identique à la production. Cette approche est incompatible avec l'Agile. Sur mes missions, j'ai construit une approche qui permet de tester la performance dès le Sprint 1 et de maintenir ce rythme sur toute la durée du projet.
Le Shift-Left Performance Testing
Le Shift-Left consiste à déplacer les tests de performance le plus tôt possible dans le cycle de développement. Concrètement :
- Sprint 0 : définir les KPIs de performance avec les Product Owners (SLA, temps de réponse cibles, throughput attendu). Ces métriques deviennent des critères de sortie de sprint.
- Sprint 1+ : intégrer un test de smoke performance dans la pipeline CI/CD. Ce test minimal (1 utilisateur, 50 transactions) permet de détecter les régressions dès le commit.
- Sprints de feature : sur chaque User Story impliquant un endpoint critique (paiement, authentification, calcul de scoring), ajouter un test de charge unitaire automatisé.
Définir les critères d'acceptation de performance
Une User Story sans critère de performance n'est pas complète. J'ai introduit le modèle SMART-Perf dans les équipes que j'ai accompagnées :
- Temps de réponse : "Le service de consultation de solde doit répondre en moins de 800ms au 95e percentile sous 500 utilisateurs simultanés"
- Throughput : "Le moteur de règles doit traiter 200 transactions/seconde sans saturation CPU"
- Taux d'erreur : "Le taux d'erreur HTTP ne doit pas dépasser 0,1% en charge nominale"
Ces critères alimentent directement les assertions dans NeoLoad ou JMeter, ce qui permet d'échouer automatiquement le pipeline si une régression est détectée.
Intégration CI/CD avec Jenkins et NeoLoad
Voici le workflow que j'utilise sur Jenkins avec NeoLoad :
- Build et déploiement automatique sur l'environnement de performance
- Déclenchement du test NeoLoad via le plugin Jenkins NeoLoad
- Vérification des SLA : si un seuil est dépassé, le build échoue et une notification est envoyée
- Publication du rapport HTML dans Jenkins pour la traçabilité
Reporting pour les cérémonies Scrum
Le Sprint Review n'est pas le bon endroit pour un rapport de tests de 40 pages. J'ai adopté un format court : 3 métriques clés + 1 tendance. Un dashboard Grafana public visible par tous les stakeholders remplace les rapports Word. Les anomalies identifiées sont directement créées comme User Stories techniques dans le backlog.
Ce qui ne fonctionne pas
Deux anti-patterns à éviter : tester sur des données de test non représentatives (volumes 10x inférieurs à la prod) et ne tester que le chemin nominal (oublier les transactions de batch, les processus asynchrones). Ces erreurs donnent une fausse confiance et les incidents arrivent en production.
Sources & références
- ISTQB — Certified Tester - Performance Testing syllabus (CT-PT) 2018
- Agile Alliance — "Performance Testing in Agile Projects" : agilealliance.org
- Scott Barber — "Why You Can't Defer Performance Testing" (2004, actualisé 2022)
- Tricentis Blog — "Shift-Left Performance Testing with NeoLoad" (2023)