Le test est sujet, comme beaucoup d’autres sujets à de nombreuses idées reçues. Cela a d’ailleurs été l’objet d’un de mes premiers articles. Cette problématique d’idées reçues est évidemment présente en Agile et donc au test Agile. En voici quelques unes qu’il m’est arrivé de rencontrer:
En Agile tous les tests sont automatisés
FAUX
C’est peut être une des idées les plus généralisées sur le test Agile. L’Agile pousse à automatiser un maximum sa régression néanmoins les tests manuels ne sont pas morts, loin de là. Les tests exploratoires sont très utiles que cela soit pour une validation ou plus simplement une acceptation faite par le PO. De manière générale il n’est pas recommandé (voir possible) de faire de la validation métier (tests d’acceptation au sens ISTQB) de manière automatisée.
Pas besoin de tests transverses/inter équipe en Agile à l’échelle
FAUX
Ce n’est pas parce que les équipes Agile font un très bon travail et qu’elles testent très bien leur périmètres que les tests inter-équipes ne sont pas nécessaires. Loin de là!
En fait les tests inter-équipes sont complémentaires aux tests des équipes Agile, ils permettent de repérer des anomalies notamment dans les interactions entre les différents composants développer dans les équipes. En fait on est un peu dans un cas de niveaux de tests encapsulés avec les développements des équipes étant des logiciels, eux-même composant d’un logiciel plus grand:
Dans tous les cas ces tests sont nécessaires car ils révèlent de nombreuses anomalies qui ne peuvent pas être détectés par les équipes Agiles.
Pas besoin de testeur dans une équipe Agile
FAUX
C’est quelque chose que l’on peut entendre, notamment de la part de personnes lisant des articles sur l’état de l’art mais ne s’étant jamais confronté à la réalité. Ce n’est pas parce qu’une équipe Agile est une équipe de développement qu’il ne faut pas de testeur!!
Cette phrase reste vraie même dans la très grande majorité (je n’aime pas dire « tous ») des contextes… même dans les contextes où il n’y a pas de professionnels du test dans l’équipe! J’ai moi même vécu une expérience où en tant que PO je ne pouvais pas être le testeur de l’équipe de développement. L’équipe, exclusivement constituée de développeurs s’est chargée de prendre le rôle de testeur. Au final un développeur s’est spécialisé dans le test. Dans d’autres cas on aurait pu avoir une prise en charge des tests par l’ensemble de l’équipe… mais dans tous les cas le rôle de testeur, existe et se doit d’être présent dans toutes les équipes Agiles.
En Agile c’est le testeur le garant de la qualité
FAUX
Là encore c’est faux et complètement faux. C’était faux en cycle V, cela reste faux en Agile. En Agile, le garant du produit et de se qualité c’est l’équipe dans son ensemble. Il n’y a pas de produit de qualité sans un travail collectif de l’ensemble des acteurs.
Le test Agile n’est pas documenté ni suivi
FAUX
On est ici sur une idée reçue qui touche l’Agile en général avec une mauvaise compréhension du manifeste Agile. Pour le test en général, les tests automatisés sont forcément documentés et suivis! De même, si on abandonne les tests scriptés pour la validation avec uniquement du test exploratoire (ce que j’ai déjà vécu) il y a un suivi avec les chartes de test!
Ce suivi est d’ailleurs primordial dans une démarche d’amélioration continue.
En Agile il n’y a pas de fiche d’anomalie
FAUX… même si peut être vu comme partiellement Vrai
On est ici sur un point un peu plus complexe que les précédents. Il y a de nombreuses équipes Agile qui ne tracent pas sous forme de fiches d’anomalie les « bugs » détectés avant qu’une US soit « Done ». Ce fonctionnement est efficace dans certains contextes car il fait gagner du temps et la communication intra-équipe peut être suffisante. Il existe aussi des solutions « light » avec des créations de « tâches » dans l’US. Dans ces contextes on peut donc parler de l’absence de fiche d’anomalie. Néanmoins il y a forcément des bugs qui surviennent en production. Dans ce cas il est vraiment intéressant de pouvoir bien tracer ces problèmes et donc d’avoir des fiches d’anomalie. Ces fiches restent très importantes dans une démarche d’amélioration continue et pour optimiser ses tests en fonction des risques.
Conclusion
Les idées reçues sont monnaies courantes. Elle prennent souvent racine sur des incompréhensions (comme pour le manifeste Agile), des extrapolations (par exemple avec les pyramides de test) ou encore des lectures sur l’état de l’art avec ce que de très grandes entreprises arrivent à faire ou mettre en place. Afin de les éviter ou de mieux les combattre il est nécessaire de bien maîtriser ses bases, comprendre d’où vient cette idée et bien sûr s’adapter au contexte!
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
