Une équipe sans testeur, ça vous dit quelque chose ? Malgré son incontestable plus-value, les réalités budgétaires font trop souvent de ce poste un oublié lors de la constitution des équipes. Comment s’assurer, en tant que Product Manager (PM), que l’équipe délivre un produit de qualité ?
Assurer la qualité des nouveaux développements
De mon expérience, limiter la charge en termes de tests passe tout d’abord par un travail important en amont. L’équipe doit s’approprier le besoin à résoudre ainsi que les critères d’acceptation. Pour ça, quoi de mieux que de les co-construire ensemble au travers d’un atelier comme le 3 amigos (mais sans testeur donc) pour arriver à un example mapping ? Cet atelier permet un alignement et une compréhension mutuelle de l’attendu final en un temps limité. Si vous avez déjà pratiqué cet exercice, vous ne serez pas surpris de voir qu’en tant que PM, il est impossible d’anticiper tous les critères d’acceptation et que l’apport d’interlocuteurs variés permet d’en identifier de nouveaux.
Travailler en amont c’est bien, mais cela ne suffit pas à garantir que le produit répondra aux attentes initiales.
La théorie veut que l’alignement sur l’attendu se fasse en amont ; et que la phase de test après le développement ne soit que peu utile. La pratique montre qu’il peut y avoir des ratés ; que ce soit un oubli fonctionnel ou un critère d’acceptation mal interprété (l’erreur est humaine). Il est important que le test soit soumis à un autre regard que celui du développeur de la fonctionnalité. Sans testeur, il faut donc trouver des alternatives. Pour cela, je vous recommande ces deux “best practices” de “pair testing”, testées et approuvées :
Le test en local avec le PM
Une fois que le développeur considère son développement fini, vous pouvez vous poser ensemble pour valider conjointement le fonctionnel. L’organisation que je préconise est de laisser, dans un premier temps, le développeur présenter la fonctionnalité. Il peut alors être intéressant d’approfondir le fonctionnel, ce qui renforcera l’ownership du fonctionnel par l’équipe. Dans un deuxième temps, vous pouvez prendre un moment, toujours en compagnie du développeur, pour pousser le test plus loin que ce qui était initialement prévu en évaluant les cas aux limites ou les cas “tordus” d’utilisation. Souvent, lorsque la fonctionnalité est disponible avec des données, on se rend compte que certains cas n’avaient pas été anticipés. C’est alors le moment de procéder à des ajustements, dans la mesure du raisonnable.
Le test croisé avec un autre développeur
Bien que le PM n’en soit pas acteur, il me paraît intéressant d’évoquer cette pratique que vous pourrez soumettre à votre équipe. En plus des code reviews basées sur la qualité du code, l’équipe peut ajouter une étape. Un autre développeur vérifie que le fonctionnel attendu est au rendez-vous. Au-delà du test, cela permet à un autre développeur de s’approprier plus en profondeur la nouveauté ; mais aussi de créer du lien dans l’équipe.
Garantir la non régression
Outre la validation des nouveaux développements, un testeur doit aussi s’assurer qu’ils n’entraînent pas une régression sur l’existant. Sans testeur, cette tâche devient l’affaire de tous.
Plus le produit grossit, plus cela devient chronophage. Pour réduire cette charge, la mise en place de tests automatisés est nécessaire, notamment :
Les tests unitaires
En tant que responsable du produit, et donc de sa qualité, vous devez vous assurer que la couverture de code en tests unitaires est un sujet traité par l’équipe. Ce qui est un premier garde-fou. En parler et surveiller son évolution lors des sprint reviews permet de sensibiliser tout le monde (équipe + parties prenantes) sur la qualité du code produit. Pour optimiser le ratio temps/bénéfice de ces tests, il faut que l’équipe définisse ensemble l’important à couvrir et configure bien l’outil permettant de surveiller cette donnée.
Afin d’avoir de bons scores (80-90%), il est important de traiter le sujet dès le début pour ne pas cumuler du retard. Autrement, rattraper le retard susciterait autant de frustration chez le développeur qu’au niveau des parties prenantes privées de nouvelles fonctionnalités.
Les tests End-to-End
La mise en place de ces tests est plus complexe. Il faut d’abord mettre en place le bon outil selon le besoin (tester une interface ou une API n’est pas la même chose) ; et bien cibler les chemins critiques. Ces tests ont un coût de maintenance qui évolue en fonction du produit. Couvrir le spectre total de l’application peut avoir un coût trop important par rapport au gain. En l’absence de testeur, l’automatisation de ces tests par l’équipe se fait au détriment du développement de nouvelles fonctionnalités, d’où l’importance de bien cadrer le sujet. À vous de trouver le bon équilibre !
Les tests unitaires doivent faire partie de votre “Definition of Done”. À l’opposé, l’automatisation d’un test “End-to-End”, doit faire l’objet d’un ticket à prioriser.
Au-delà de ces automatisations de tests qui concernent l’ensemble de l’équipe, le PM a son rôle à jouer pour garantir une non régression. Il se doit de maîtriser son périmètre et de tester son application le plus souvent possible. Se réserver un créneau une fois par semaine et lancer des tests exploratoires peut permettre de toucher à d’anciennes fonctionnalités et faire remonter des dysfonctionnements. Cette pratique est aussi utile pour nourrir votre réflexion sur de nouvelles fonctionnalités à mettre en place. Testez, le gain est double !
Les limites à se passer de testeurs
Amis décideurs, à la lumière de tous ces éléments, vous pouvez vous demander si le rôle d’un testeur dans l’équipe est vraiment nécessaire. Pour y répondre, il faut prendre en compte trois aspects :
L’impact de l’équipe sur la capacité à produire
Même si certaines pratiques (example mapping, couverture de tests unitaires) sont pour moi non négociables, d’autres tâches demandent du temps à l’équipe et au PM, au détriment du reste. Si la charge d’un testeur par équipe vous semble trop importante, il peut être intéressant de mutualiser cette charge avec d’autres équipes et ainsi libérer de la charge pour la vélocité de l’équipe.
Le niveau minimum de qualité attendue
La qualité d’un produit est importante mais selon le produit, l’attendu minimum n’est pas le même. Un produit très critique dans un domaine tel que la banque (où l’anomalie peut avoir un impact très important) se passe difficilement d’un testeur. À l’opposé, un MVP ayant pour principal objectif de valider quelques hypothèses avec un niveau de qualité minimum (car potentiellement jetable) n’aura pas forcément besoin du même investissement.
Le cycle de vie dans lequel se trouve le produit
Un produit en pleine construction aura des besoins importants en tests. À l'inverse, un produit en fin de vie pourra se passer de testeur, surtout si l’automatisation des tests est déjà en place et que l’équipe maîtrise son implémentation.
Vous l’aurez compris, hormis quelques contextes spécifiques, se passer d’un testeur est bien possible à condition que la qualité soit la préoccupation de toute l’équipe. En dernier recours, il est aussi possible de faire appel à ceux qui connaissent le mieux votre application : les utilisateurs ! Les sondages, les notes des stores ou autres demandes de feedbacks peuvent être une source importante pour l’identification de bugs à traiter. En plus de vous aider dans la quête du produit à zéro bug, cela permet de créer du lien et de l’engagement chez vos utilisateurs. C’est le fameux double effet Kiss Cool.
En résumé, mes conseils à un PM qui se retrouve dans ce type de contexte seraient :
- Organise des ateliers d’example mapping
- Teste le plus tôt possible avec le développeur
- Trouve le bon niveau et favorisez l’automatisation de tests
- Passe du temps pour procéder à des tests exploratoires
- Sensibilise les stakeholders sur le fait que ne pas avoir de testeur a un impact sur la vélocité de l’équipe
- Sois à l’écoute de vos utilisateurs qui peuvent vous remonter des régressions
Pour aller plus loin : télécharge le livre Les Clés du Product Management
