Je vais cracher dans la soupe qui me nourrit depuis 18 ans.
Une grosse part des tests de charge que j'ai vus étaient inutiles.
9 fois sur 10, les défauts trouvés auraient pu être détectés en cramant nettement moins de blé et de temps.
Le réflexe, quand un service se traîne en charge à gros volumes, c'est de sortir l'artillerie lourde.
Une préproduction qui coûte un PEL, des datasets obèses, Jean-Michel Bourrin qui balance 10 000 requêtes/seconde et pose sa conf de presse « mission accomplished ».
Bravo.
C'est le début d'une boucle test - fix avec : - des QA aux tests fragiles à cause de paramètres mal maîtrisés - des devs qui font des micro-ajustements au doigt mouillé faute d'accès à l'APM
Et on itère, parce qu'après tout c'est ça l'Agilité. Non ?
Je me revois devant un flame graph. Toute l'équipe pensait au dialogue avec la base de données. On avait des mois d'allers-retours mous derrière nous. Sous mes yeux, la preuve irréfutable que ça venait en fait des allocations mémoire et des attentes d'écritures disques.
Tous ces efforts pour un truc qu'on aurait pu trouver en 3 jours de pairing.
J'étais dégoûté.
Tant que tu connais pas en détail le fonctionnement pour 1 utilisateur, pourquoi tes équipes testent pour 1 million ?
Vise petit, et analyse à mort. Plus tard, le gros test prendra tout son sens. Il débusquera ce qu'aucun œil ne repèrerait seul.
C'est bien d'avoir de l'ambition, mais mettre la charrue avant les bœufs n'aide personne.
Tes devs vont s'user, tes QA vont cravacher sans impact, et tu vas te demander pourquoi c'est si compliqué.
Ton caillou dans la chaussure, depuis le début, c'est le manque de méthode.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →