4 erreurs fatales du test de performance que tu as commises à coup sûr.
Est-ce que tu continues ?
1/ Tu ne connais pas le métier de la boîte.
Tes jeux de données sont de mauvaise qualité.
Tes scénarios utilisateur sont faux.
Tes stats de fréquentation étaient déjà à la rue l’an dernier.
Tu ignores ce que fait le produit en détail et comment son public fonctionne.
Preuve ? T’es incapable de vulgariser l’info pour quelqu’un d’extérieur à la tech.
2/ Tu n’as pas d’objectif.
Tu lances des tests sans savoir ce que OK ou KO signifient.
Tu balances des moyennes générales alors que tu as 3 populations utilisatrices radicalement différentes.
Tu testes pour faire plaisir à ton PM qui veut “un premier feeling”.
Si t’as pas de cible, tes fléchettes vont dans le mur.
3/ Tu produis au lieu de réfléchir.
Tu empiles les tentatives.
Tu multiplies les hypothèses.
Mais tu mets 10 fois moins de sueur sur tes analyses.
Un médecin qui dit "18/9 de tension" et "ça fera 25 euros" dans le même souffle.
4/ Ta stratégie tient en un mot.
C’est ta plus grosse erreur.
Quel que soit le problème, l’approche est la même.
Tester en charge ? Tu foudroies le frontend avec des centaines d’utilisateurs virtuels.
Tester la performance ? Tu scandes test de charge.
Améliorer la performance ? Vite, un test.
Quand on a qu’un marteau, on voit que des clous.
Parfois on a besoin d’un test de charge, parfois d’une étude de la prod.
Parfois de l’équipe experte en test, parfois d’onboarder les devs sur du self-service.
Aller, on arrête de suer pour rien ? ☠
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →