Comprenez le rôle du testeur
“Les tests ne servent à rien. Il suffit de vérifier le code et de déployer en production.”
On entend souvent ça. Pourtant un testeur est bien utile dans une équipe ! Voyons un peu à quoi il peut servir.
La principale mission d’un testeur est de contrôler si un nouveau produit informatique (logiciel, équipement, système, etc.) est conforme au besoin. Pour vérifier la conformité d’un produit, le testeur doit :
prendre connaissance des spécifications du produit et des normes qui lui sont imposées ;
créer différents outils de test afin de préciser et définir tous les points à vérifier ;
effectuer des tests jusqu’à ce que chaque point soit validé et conforme ;
reporter avec précision les résultats une fois tous les tests effectués.
Tester c’est faire trois choses essentielles :
Vérifier : s’assurer que les choses sont faites conformément à ce qui a été défini.
C’est se demander “est-ce que ça marche ?”, “est-ce que ça fonctionne ?” par rapport à ce qu’on a défini au préalable de manière explicite (dans un cahier des charges technique ou une user story).
Valider : s’assurer que l’objectif initial est atteint.
C’est se demander “est-ce que ça convient à mon utilisateur ?”, “est-ce que cette solution répond correctement à un besoin de mon utilisateur ?”
Explorer : s’assurer que les spécifications implicites sont prises en compte dans l’activité de test.
C’est se demander “est-ce que le système est robuste ?”, “est-ce qu’il est performant ?”, “est-ce qu’il y a des anomalies cachées ?”
Les missions d’un testeur peuvent être très variables en fonction de ses appétences et des projets sur lesquels il intervient. Il peut :
être uniquement un testeur “presse-bouton”, c’est-à-dire qu’il se contente d’exécuter un plan de test déjà écrit, de noter si le test est valide (“OK”) ou non (“KO”) et, dans ce dernier cas, de reporter l’anomalie ;
faire de l’automatisation, c’est-à-dire réaliser des scripts qui vont tester le produit sans intervention humaine ;
aider à concevoir les nouvelles fonctionnalités, accompagner les développeurs pour une meilleure qualité du code, etc. ;
réaliser des tests de performance, de charge, de stress ;
gérer le pilotage des tests ;
suivre les anomalies ;
insuffler l’esprit de la qualité au sein de son équipe.
Maintenant que vous avez connaissance des principales tâches effectuées par un testeur, sachez que celui-ci travaille en équipe. C’est quelqu’un sur qui on doit pouvoir compter, sur qui s’appuyer et à qui on peut faire confiance. Cela nous amène donc à la place qu’occupe le testeur dans une équipe et aux différents membres qui la composent.
Situez le testeur dans une équipe
Que vous soyez dans une équipe agile (développement itératif) ou non (développement séquentiel), vous retrouverez sensiblement les mêmes acteurs.
Dans une équipe structurée en méthode itérative (agile), on retrouve :
le Product Owner (ou PO) qui représente le client. Il définit les nouvelles fonctionnalités à ajouter au produit ou les améliorations de l’existant ;
le Scrum Master qui s’assure que toute l’équipe comprend Scrum et l’applique correctement. Il interagit avec les membres de l’équipe Scrum (le Product Owner et l’équipe de développement) et l’ensemble de l’organisation afin de maximiser la valeur créée par l’équipe Scrum ;
les UX/UI Designers qui créent les parcours utilisateurs et les visuels :
L’UX crée l’enchaînement des écrans d’un site web ou d’une application. Il schématise les éléments importants de chaque écran pour montrer comment passer de l’un à l’autre.
L’UI prend chaque écran pour disposer les éléments sur la page et les coloriser. Il fait en sorte que l’écran soit compréhensible et intuitif pour l’utilisateur.
L’UX et l’UI sont là pour faire en sorte que l’expérience utilisateur soit la meilleure et la plus fluide possible.
les développeurs réfléchissentt à la meilleure manière de coder les fonctionnalités souhaitées par le Product Owner puis les développer ;
les testeurs s’assurent que ce qui a été développé par les développeurs correspond bien aux spécifications.
Dans une méthode séquentielle (dite cycle en V ou en cascade), on retrouve les mêmes intervenants, sauf le PO qui est typique de l’équipe agile. Il sera remplacé par le chef de projet.
Voyons maintenant plus en détail la relation du testeur avec certains membres de l’équipe.
Identifiez la relation entre le testeur et le développeur
Les testeurs et les développeurs travaillent souvent ensemble. Ils sont amenés à échanger régulièrement. Ils sont là pour assurer la qualité du produit. Mais ça n’a pas toujours été le cas.
Dans les premiers projets de développement, le testeur n’existait pas. C’était le développeur qui vérifiait son code. Il testait son code mais ne faisait pas de vrais tests de bout en bout. Et il a bien fallu admettre que parfois le travail du développeur n’était pas parfait et qu’il serait intéressant d’avoir quelqu’un d’extérieur au développement pour le vérifier.
Cette personne, c’est le testeur ! Quelqu’un d’impartial et qui n’aura pas de parti pris.
Le développeur et le testeur n’ont pas la même posture vis-à-vis du logiciel :
Le développeur conçoit un logiciel à partir de spécifications (cahier des charges, expressions de besoins, etc.).
Le testeur va chercher par tous les moyens à vérifier que le logiciel ne comporte pas de bugs.
L’un va suivre les spécifications pour construire le logiciel et développer les cas nominaux. C’est-à-dire les cas pour lesquels le logiciel a été spécifié. L’autre va tester ces cas nominaux mais va aussi tester les chemins détournés que pourrait prendre un utilisateur.
Par exemple, un cas nominal serait le clic sur un bouton dans un parcours d’achat pour valider une commande.
Et un chemin détourné ou une utilisation non prévue pour ce même cas seraient que l’utilisateur double-clique sur ce bouton, ce qui aurait pour effet d’envoyer deux commandes.
C’est pour ça que ces deux types de personnes doivent trouver un moyen de collaborer pour avoir un logiciel de la meilleure qualité possible. 😉
Pourtant dans certaines équipes il n’était pas rare d’entendre :
“Encore un bug remonté par le testeur, il fait n’importe quoi aussi, ce n’est pas censé fonctionner comme ça !”
“Pfff, le développeur n’a pas encore testé son dev et il nous livre ça. C’est plein de bugs.”
Ou encore, quand un testeur n’a pas mis assez d’infos sur son rapport d’anomalies et que le développeur, qui a essayé de le reproduire, répond :
“Ça marche sur ma machine, il n’y a pas de bug.”
Ce qui nous amène au fait que chacun doit comprendre l’autre et sa position :
Au développeur de comprendre que l’utilisateur ne respectera pas forcément le cas nominal lors de son utilisation du logiciel et que c’est pour ça que le testeur teste un maximum de cas d’utilisation.
Au testeur de comprendre que le travail du développeur n’est pas de tout tester mais de livrer un logiciel qui respecte les spécifications.
Passons maintenant à la relation du testeur avec un autre membre de l’équipe, le Product Owner.
Identifiez la relation avec le PO ou chef de projet
Le Product Owner représente la voix du client. C’est lui qui va rédiger les User Stories.
Dans une équipe non agile, ce ne sera pas le chef de projet mais le business analyste qui rédigera les spécifications.
Le testeur intervient à diverses étapes du cycle produit et travaille en étroite collaboration avec le PO. Par exemple, le testeur participe activement à l’élaboration des critères d’acceptation.
Il faut bien comprendre que même si les rôles des développeurs, testeurs, et Product Owner sont définis, ils ne sont pas figés :
Un développeur pourra remonter un problème utilisateur ou une opportunité de résoudre un problème après une discussion avec des utilisateurs du produit.
Le PO pourra remonter un bug car il aura effectué quelques tests pour s’assurer que l’équipe de réalisation va dans le bon sens.
Tous les membres de l’équipe participent d’une manière ou d’une autre à la qualité logicielle. Casser les silos pour travailler ensemble, cela permet de réduire la boucle de feedback au sein de l’équipe. Et, par conséquent, cela permet de satisfaire plus vite et encore mieux les utilisateurs.
En résumé
Les missions d’un testeur sont multiples et variées.
Le testeur est amené à collaborer en équipe.
Il a notamment une relation privilégiée avec les développeurs.
Il accompagne le Product Owner sur la rédaction des critères d’acceptation, ce qui lui permet de bien comprendre les attentes des utilisateurs.
Maintenant que vous en savez un peu plus sur le métier de testeur, dans le chapitre suivant nous allons voir plus en détail l’intérêt des tests, ainsi que les types de tests auxquels le testeur pourra être confronté.
