En test de charge, beaucoup de QA fonctionnel gaspillent leur impact.
Quand un défaut fonctionnel est signalé, quel est le premier truc que font les devs ? Reproduire. Pointer le défaut suffit. Alors les QA font pareil sur la charge et ça tire leur impact vers zéro.
On colle la sortie de l'outil d'injection dans une page Confluence, avec une liste de temps de réponse, et hop c'est plié.
J'admets, je l'ai fait aussi.
Sauf que ça déclenche strictement rien ; tout le monde ronfle.
Les devs en face peuvent pas reproduire le test. L'environnement n'est pas dispo, les outils non plus, et pas de méthodo. Ton défaut tournera jamais sous leurs yeux.
Donc pointer suffit pas. Il faut ouvrir le capot, expliquer le mécanisme, prouver par l'expérimentation d'où vient le problème, et avoir un AVIS.
Sur une migration de référentiel que je testais, l'extracteur continuait de tourner alors que l'injecteur avait crashé en silence. Un rapport aurait constaté le symptôme. Il a fallu une argumentation déroulée 1 fois, 2 fois, 3 fois, pour que l'architecture soit revue et que les deux composants finissent par se parler.
J'en suis sorti avec une bien meilleure compréhension du contexte métier, et mon collègue a gagné une crash course en ingénierie de performance.
Alors ma proposition est simple.
Si t'écris encore des rapports et que tu vois aucun impact, arrête d'en écrire. (champagne !)
Remplace-les par une discussion avec les devs, et un follow-up au sprint suivant. Deux questions suffisent :
→ Pourquoi ? Pour comprendre le système avec quelqu'un qui le voit autrement.
→ Et maintenant ? Pour savoir ce qui sera vraiment corrigé.
En fonctionnel, tu pointes et tu passes à la suite. Sur la charge, c'est là que ton boulot commence.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →