En tests de charge, beaucoup de QA fonctionnel se planquent derrière un rapport que personne ne lit. Voilà ce qui fait vraiment bouger les devs :
Dans les environnements très corporate, difficile d'être proche des équipes de dev. Alors on jette un document par-dessus la clôture, parfois même un vulgaire copier-coller de l'outil d'injection.
J'admets, je l'ai fait.
Sauf que ce rapport change rien à la mayonnaise.
Les devs peuvent même pas reproduire les tests de leur côté. Le rapport est lu 5% du temps, et oublié à la seconde même où on le publie.
Vécu sur une migration de schéma de données : un extracteur continuait à tourner alors que l'injecteur avait crashé. J'ai dû argumenter 1 fois, 2 fois, 3 fois le comportement à adopter pour que ce soit robuste "by design". C'est cette discussion qui a fait refactorer l'architecture pour que les 2 composants se parlent enfin.
Si j'avais fait un rapport ? Le dev l'aurait même pas lu.
Un rapport ferme le chapitre là où une discussion ouvre des portes. C'est en posant de bonnes questions qu'on s'instruit et, si on a de la chance, qu'on influence.
Deux questions à poser encore et encore : → Pourquoi ? Pour comprendre le système. → Et maintenant ? Pour savoir ce qui sera corrigé derrière.
Dans une campagne de tests, on cherche à corriger le défaut. Prouver qu'on a bossé n'a jamais rien réparé.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →