Le métier de testeur est un métier technique qui exige des compétences spécifiques. Il semble donc évident que les testeurs soient confrontés à des défis liés à la nature technique des tests ou à certaines activités.
Cependant, comme tout autre métier, le test ne se limite pas à des questions purement techniques ! C'est d'autant plus vrai dans le domaine du test, où les testeurs doivent communiquer sur des notions telles que la qualité, la gestion des risques et la confiance avec un large éventail de personnes issues d'horizons divers.
Dans cet article, nous présentons certains des défis relationnels auxquels les testeurs sont fréquemment confrontés.
Les équipes agiles sont de petites équipes pluridisciplinaires. Elles doivent disposer de toutes les compétences nécessaires à la création du produit sur lequel elles travaillent. Cela inclut toutes les compétences en matière de tests (analyse, conception, communication, automatisation…), alors que dans de nombreuses équipes, il n’y a qu’un seul testeur… qui doit donc, en théorie, posséder toutes ces compétences… ce qui est rarement le cas.
De même, une équipe agile est, comme son nom l’indique, une « équipe ». Il s’agit d’un groupe de personnes, et l’intégration au sein d’un groupe n’est pas nécessairement facile.
Enfin, une équipe agile travaille sur un produit qu’elle connaît généralement très bien. Rejoindre une équipe en cours de route nécessite donc d’acquérir de nouvelles compétences.
La combinaison de ces trois points pose de réels défis au testeur, qui doit être accepté par l’équipe tant sur le plan humain que sur le plan opérationnel, en tant que référent qualité et test… sur le produit en cours de développement.
La combinaison de ces compétences conduit parfois à un rejet de la part de l’équipe Agile, qui peut considérer, au bout d’un certain temps, que le testeur n’apporte pas autant qu’on l’espérait.
Il est très rare qu’un testeur possède toutes les compétences requises par une équipe Agile. Si l’on ajoute à cela la capacité à bien comprendre et connaître le produit, ainsi qu’une bonne entente avec tous les membres de l’équipe, on entre dans le domaine du tout à fait improbable.
Il ne faut pas oublier qu’en tant que testeur Agile, vous faites partie d’une équipe. Et dans une équipe, que ce soit en Agile, dans le sport ou dans tout autre domaine, on s'entraide. En tant que testeur, vous ne devez pas hésiter à collaborer avec les autres membres de l'équipe (développeurs, métier, opérations, etc.) et à demander de l'aide pour certaines tâches que vous ne maîtrisez pas encore.
De même, c’est toujours une bonne idée d’échanger des idées avec vos pairs au sein de communautés ou lors d’événements dédiés aux tests, afin d’améliorer vos compétences dans certains aspects du test.
Enfin, il est tout aussi important de ne pas vouloir tout révolutionner avant d’avoir pleinement compris le contexte, les besoins, les problèmes, les points forts de l’équipe et, surtout, son produit. Vouloir tout changer sans avoir acquis de légitimité au sein de l’équipe est souvent synonyme de rejet, mais aussi de recommandations inappropriées.
Détecter les anomalies, c'est bien, mais corriger celles qui doivent l'être, c'est mieux. Il en va de même pour les actions d'amélioration : les identifier, c'est bien, mais les mettre en œuvre, c'est mieux.
Vous avez sans doute déjà reconnu certaines situations. Le travail du testeur ne se limite pas à identifier les défauts, à évaluer les niveaux de qualité ou à identifier des actions d’amélioration. Il est essentiel que ce travail débouche sur des progrès et des améliorations. Malheureusement, être convaincu de la validité de ses actions (ou d’avoir raison) ne suffit pas pour convaincre ses interlocuteurs.
Les tests dépendent du contexte, tout comme la communication avec vos différents interlocuteurs !
Il est important de bien connaître les personnes avec lesquelles vous travaillez, ainsi que le produit que vous testez, afin de pouvoir trouver les bons arguments pour corriger un problème, initier des actions d’amélioration ou signaler un niveau de qualité insuffisant.
De même, la communication avec les techniciens (par exemple, les développeurs de l'équipe) et les responsables fonctionnels (par exemple, le Product Owner, le chef de projet, etc.) doit être différente, car les attentes et les objectifs ne sont pas les mêmes.
Il est également important de savoir quand une bataille est « perdue d’avance », afin de ne pas vous épuiser. Mettre en œuvre une stratégie de test peut s’avérer utile… Mais si vous ne parvenez pas à convaincre les membres de votre équipe, c’est peut-être parce que celle-ci n’en ressent pas encore le besoin, ou parce qu’il existe d’autres problèmes plus prioritaires.
Il est normal de vouloir réutiliser des techniques, des stratégies ou des approches de test qui ont fait leurs preuves dans nos contextes précédents. Il est courant de vouloir utiliser des outils que l’on maîtrise et qui nous sont familiers.
Malheureusement, cette approche atteint rapidement ses limites, car les tests dépendent du contexte, et ce contexte dépend à la fois du logiciel sur lequel nous travaillons et du temps dont nous disposons. Ainsi, même si nous continuons à travailler au sein de la même équipe et sur le même produit, les approches de test, tout comme les tests eux-mêmes, finissent par s’essouffler (le paradoxe du pesticide).
Pour éviter une dégradation de la qualité, il est essentiel de se remettre régulièrement en question et de s’interroger afin d’évoluer avec le contexte.
Il est important de connaître la production sur le bout des doigts, de faire avancer vos campagnes et d’échanger des idées avec les membres de votre équipe et vos pairs afin d’identifier les faiblesses potentielles et les axes d’amélioration.
En effet, il faut rester curieux et avoir une envie constante d’aller de l’avant. Rien ne peut jamais être tenu pour acquis… et c’est ce qui rend le métier de testeur si fascinant… et si difficile à automatiser !
Définir un niveau de qualité est une tâche complexe. Pour ce faire, il faut définir son approche en matière de tests. Malheureusement, il ne suffit pas de définir ce niveau ! Il est important que le testeur soit capable de faire comprendre ce niveau de qualité à ses interlocuteurs.
Les indicateurs constituent un bon moyen d’y parvenir, mais en fin de compte, ils ne suffisent pas. Un testeur doit être capable de transmettre rapidement les tenants et aboutissants du déploiement en production. Quels sont les risques ? Quels sont les défauts connus et non corrigés ? Quel est leur impact ?
Vous verrez que c’est là le rôle d’un livrable bien connu : le bilan ! Dans la pratique, vous devez travailler dur sur cette analyse, mais aussi vous entraîner à présenter les faits de manière concise et claire à l’oral pour vous assurer que vous les comprenez bien.
Il est important de définir clairement vos indicateurs et de les rendre transparents. Cela nécessite une bonne gestion de la traçabilité. La communication doit également être adaptée au public… ce qui nous ramène au défi consistant à « convaincre votre public ».
Les tests sont généralement considérés comme un centre de coûts. Même si cette opinion persiste, les faits démontrent le contraire. Si ce n'était pas le cas, les entreprises ne feraient pas de tests !
Il n’en reste pas moins important d’investir dans les tests afin de les rendre plus efficaces, ce qui n’est pas toujours facile. En effet, le budget alloué au développement de produits logiciels est limité, et l’investissement dans les tests se fait « au détriment » de fonctionnalités supplémentaires potentielles.
Il est important de faire prendre conscience aux différents acteurs de la « valeur des tests », de leur rappeler les avantages de ces derniers, tant d’un point de vue financier que non financier.
Du point de vue financier, il existe des indicateurs courants tels que le coût de la détection des bogues en production et lors des tests. Ce calcul met en évidence les économies réalisées grâce aux tests, qui permettent de détecter les bogues. Il est également possible de disposer d’indicateurs sur les gains de temps, notamment le pourcentage de temps consacré à la correction des bogues en production.
D’un point de vue non financier, les tests fournissent des informations de qualité pour la prise de décision. L’information est un élément essentiel, et même si elle ne génère pas directement de revenus, elle apporte de la confiance. Les tests garantissent également un niveau de qualité qui renforce l’image de marque de l’entreprise et/ou du logiciel. Cette qualité fidélise les clients et attire de nouveaux utilisateurs !
Pour en savoir plus sur les défis auxquels sont confrontés les testeurs, restez à l’écoute. Je partagerai bientôt avec vous les défis techniques et quelques conseils associés.