Introduction :
Comme beaucoup de métiers, le métier du test véhicule de nombreux clichés. Faisons un tour d’une partie de ceux-ci et analysons-les ensemble.
Les idées reçues :
1. Les tests ça coûte cher
· OUI et NON. En effet mettre en place de process de test coûte de l’argent. Par contre ces process permettent souvent de repérer des bugs et donc de les résoudre. De nos jours, sortir une application inutilisable car trop buggée signifie la mort de cette application, notamment avec le système de note et d’avis sur internet.
· Les bonnes procédures de tests ont un bon retour sur Investissement
2. Les tests c’est à la fin du projet
· FAUX, plus les tests commencent tôt mieux c’est. Même les spécifications peuvent être testées, je conseille même fortement de le faire. Une erreur trouvée dans les spécifications ne coûte quasiment rien à corriger !
3. Le projet est en retard c’est à cause des tests
· FAUX, si les tests sont en retard cela peut être pour plusieurs raisons : une livraison tardive, une qualité pas au rendez-vous, des problèmes sur la plateforme de tests… Si un projet est en retard ce n’est pas forcément la faute du dernier maillon de la chaîne. Comme tout acteur du projet, le testeur souhaite une sortie en temps et en heure de l’application.
4. Plus il y a de tests mieux c’est
· FAUX, le nombre de tests ne garantit pas la qualité de ses derniers ni une bonne couverture. Comme vu dans mon article sur le logiciel sans bugs, on peut avoir 56 000 tests sur l’authentification sans tester le reste de l’application. Je préfère nettement la même application avec 200 tests et uniquement 5 tests sur l’authentification.
· De plus un grand nombre de tests signifie avoir assez de temps pour les maintenir ou les analyser. Des tests qui ne sont pas à jours ne sont pas intéressants, des tests non analysés n’ont pas d’intérêt non plus.
5. Il faut automatiser tous les tests
· Comme déjà discuté sur mon article tests auto vs tests manuels, il faut automatiser les tests que l’on exécute fréquemment. De plus certains tests sont très difficiles à automatiser et il vaut mieux les laisser en manuel. Enfin, je conseille toujours de garder au moins une partie de tests exploratoires.
6. Une application avec des bugs est une application non ou mal testée
· FAUX, on ne peut pas détecter tous les bugs et même si on les détecte on ne les corrige pas forcément. De plus ce n’est pas le testeur qui a introduit les bugs! Ils viennent à 70% des spécifications et à 30% du développement (d’après les études les plus reconnues).
7. Les testeurs n’y connaissent rien en technique et en développement
· FAUX, il y a différents types de testeurs. Certains sont plus techniques que d’autres. Ce n’est pas parce que l’on est testeur que l’on ne comprend rien au développement et à ses problématiques. Un bon nombre de testeurs a une expérience en développement (ou en automatisation de tests) ou une formation d’ingénieur. De plus les testeurs intégrés aux équipes Scrum vivent au contact des développeurs ce qui leur permet de beaucoup mieux comprendre la partie technique du projet, au point de dépanner les développeur quand l’équipe en a besoin.
8. Le test c’est le travail des testeurs
· FAUX, le test doit être à tous les niveaux du projet, de l’écriture des spécifications (avec des revues), au développement (avec les tests unitaires), jusqu’aux tests fonctionnels (les tests au sens commun du terme)….
9. Les tests il suffit de les exécuter
· FAUX, l’exécution des tests seule ne sert à rien. Un test en échec doit être analysé afin d’avoir une plus-value. De plus avant de les exécuter il faut les définir, les écrire puis les maintenir.
10. Le métier du test c’est uniquement s’occuper des tests
· FAUX, le métier du test c’est aussi beaucoup de communication et de compromis. Je vous invite à lire mon article à ce sujet pour plus d’information : « Testeur » c’est quoi ?
11. N’importe qui peut être testeur
· FAUX, pour être testeur comme pour être développeur, business analyste ou commercial il faut avoir certaines qualités. Les principales étant de mon point de vue la curiosité, une bonne communication et une bonne compréhension fonctionnelle du produit.
12. Le testeur est l’ennemi du développeur
· FAUX, le testeur a le même but que le développeur : livrer un logiciel de qualité apprécié par l’utilisateur final. Un testeur ne remonte pas un bug par plaisir.
13. Le test c’est uniquement les tests fonctionnels
· FAUX, le test c’est l’ensemble des processus visant à améliorer ou assurer la qualité d’un logiciel.
Conclusion :
Comme tous les métiers, le test véhicule des préjugés, et comme souvent ces préjugés sont une simplification à l’extrême du métier et donc faux. Il faut néanmoins les connaitre afin de mieux lutter contre.
N’hésitez pas à rejoindre le groupe Le métier du test
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles.
« Comme déjà discuté sur mon article tests auto vs tests manuels, il faut automatiser les tests que l’on exécute fréquemment »
> Pas uniquement!
J’aimeJ’aime
Le testeur est l’ennemi du développeur
· FAUX, le testeur a le même but que le développeur : livrer un logiciel de qualité apprécié par l’utilisateur final. Un testeur ne remonte pas un bug par plaisir.
Je rajouterai :
« le testeur, c’est un gros « chieur » pour les devs »
On les challenge au quotidien, on remet en question leur travail pour améliorer la qualité du livrable.
J’aimeJ’aime
Bonjour Hatenak,
c’est dit de manière un peu rude mais c’est en effet souvent ce qui est pensé. Le problème vient généralement d’une mauvaise communication.
J’aimeJ’aime
[…] des travaux finis. Il en donc peu valorisant de se dire « testeur ».Ces idées préconçues sont évidemment fausses (par exemple, les tests doivent intervenir tôt, notamment avec du shift […]
J’aimeJ’aime