Le PO doit-il être en charge des tests fonctionnels ?

Lors de ma carrière, je n’ai jamais réalisé les test fonctionnels moi-même.

Cela va paraître bizarre à certains, mais jusqu’à ce que je débute ce blog, je ne m’étais jamais posé la question.

Seulement voilà, depuis quelques mois, vous êtes plusieurs à me demander comment je gère la période de recette.

• Comment gères-tu la recette en parallèle de toutes les activités de PO ?
• Comment rédiges-tu les scénarios de tests ?
• Fais-tu des tests automatisés ?
• Etc…

Si vous êtes product owner et que vous en charge de la recette, je vous donne les raisons de votre burn out ou de votre stress.

Plus que tout, je vous explique dans un post engagé pourquoi ce n’est pas à vous de gérer les tests (si, si…. vous ne rêvez pas).

La France est-elle en retard sur le sujet ?

La confusion :

Quand j’ai commencé à recevoir toutes ces questions sur la recette, j’avoue que je me suis senti dérouté.
Au départ, je pensais que la première personne qui m’avait posé la question évoluait dans un environnement dysfonctionnel.
Je me suis dit, 

“La pauvre, son organisation ne comprend vraiment rien aux responsabilités du PO.
Son boss profite de sa naïveté et de sa gentillesse”

Puis, 1 semaine après, un autre PO m’a posé la même question. Puis encore un autre quelques temps après.

En tout, près d’une personne sur 6 aborde ce sujet là avec moi spontanément.

1 sur 6 c’est énorme, ca fait plus de 15%. 

Et comme je n’ai pas posé la question au 85% restant, c’est certainement plus.

Le moment de doute :

Au bout d’un moment, j’avoue que toutes ces questions m’ont mis un sacré doute.

Comment ai-je pu rater quelque chose d’aussi important depuis toutes ces années ?

Pourquoi personne ne m’avait jamais parlé de ça auparavant ?

J’en ai parlé autour de moi dans mon univers professionnel et évidemment tous mes collègues et ex-collègues m’ont dit la même chose.

Réaliser les test fonctionnels soi-même ??? Mais t’es fou ?
 Et puis-quoi encore ?

L’explication :

Et puis d’un coup, j’ai compris. L’évidence était devant moi.

Ca fait des années que je bosse à l’étranger.

Etats-Unis, Angleterre, Espagne… Tout le temps dans des boîtes au management anglo-saxons.

En revanche, toutes ces questions au sujet des tests qui viennent à moi proviennent des lecteurs de ce blog.

Dans la majorité, vous êtes des PO évoluant en France dans des boites françaises (petites, moyennes ou grandes).

Est-ce là l’explication ?
En théorie, ça n’a pas de sens. L’agile ou le scrum n’est pas une affaire de territoire.

J’avoue ne pas avoir de statistiques fiables à ce sujet, mais faute de mieux c’est l’explication qui me paraît la plus crédible.

Si c’est vrai, une partie des boites en France à vraiment du retard par rapport à ses voisins sur ce sujet.

J’y reviendrai plus tard dans un post sur le “Management à la française”.

Pourquoi ce n’est pas à vous de faire les tests ?

Vous n’avez pas le temps

J’enfonce une porte ouverte mais c’est l’évidence.

Daily, sprint planning, sprint review, retro, poker grooming, réunions stratégiques, réunions de crise, écritures des US, priorisation du backlog, étude de marché, tests AB…..  

Comment voulez-vous prendre le temps de tester correctement chacune des fonctionnalités et US après tout ça ?

Pour tout ceux qui lisent cet article et qui se tapent en plus les test fonctionnels, expliquez moi comment vous faites ? Ce n’est pas humain.

A vrai dire, si vous faites tout ça, il y a vraiment peu de chances que vous ayez le temps  de lire ce blog 😉

Vous n’avez pas l’expertise

En plus du temps, vous n’avez pas l’expertise.

Perso, s’il y a des head of products ou des dirigeants dans la salle qui lisent également ce blog et qui confient tous les tests fonctionnels à leurs product owners, qu’ils se lèvent.

J’ai une seule chose à vous dire : vous êtes des inconscients.

Je m’explique.

Les test fonctionnels nécessitent une étude approfondie des user stories afin de rédiger des scénarios de tests fiables.

Par ailleurs la maîtrise et la maintenance des différents environnements de Dev, Pre-prod voire environnement de démo nécessitent une expertise technique accrue.

Je ne parle même pas du temps nécessaire pour réaliser tous les tests unitaires ou l’expertise qu’il faut avoir pour mettre en place des tests automatisés.

En gros, confiez ça à une personne qui ne vient pas forcément d’un univers technique (cf : Comment devenir un product owner ? ) est non seulement une erreur de casting mais représente également un gros risque sur la qualité produit.

Ce n’est pas parce que le product owner est garant de la qualité du produit (ainsi que toute l’équipe) qu’il doit porter la responsabilité de tester le produit.

Compter sur le PO pour endosser ce rôle représente une double peine pour l’équipe produit.

• Primo, le temps dédié aux tests va forcément pénaliser le flux de spécifications
  
• Deuxio, vos tests produits seront baclés par manque d’expertise et vous risquez de vous retrouver avec des failles en prod à corriger dans le futur.

La recette est aussi importante que le développement de la fonctionnalité.
C’est une chose à prendre très au sérieux et à faire avec professionnalisme.

Qui doit faire les tests ?

L’ingénieur QA

Ingénieur test, testeur, testeur Q/A ou ingénieur Q/A… appelez comme vous le voulez.

Il y a plusieurs noms et honnêtement je ne suis pas assez expert pour vous dire s’il y a vraiment une différence.

Ce que vous devez retenir c’est que c’est lui et normalement lui seul qui est responsable des tests.

Si vous êtes constitué en squad ou équipe fonctionnelle, le testeur Q/A est un membre à part entière de l’équipe d’un PO au côté des développeurs et éventuels UX designer, analyste produit etc…

Quel est son périmètre ?

Le testeur Q/A intervient à divers étapes du cycle produit et travaille en étroite collaboration avec le PO.

Personnellement, au niveau fonctionnel, c’est la personne de mon équipe avec qui je collabore le plus.

En stade de pré-développement.

Au moment des spécifications, lorsqu’elles sont terminées et que je les présente en backlog grooming, le testeur Q/A est un membre prépondérant de la cérémonie.

C’est lui en général qui pose le plus de questions sur les US afin de pouvoir rédiger les scénarios de test.
Je profite de ses remarques pour rédiger et ajouter des critères d’acceptances dans l’US et avec mon équipe nous prenons en compte le temps de test pour chiffrer l’intégralité de l’US.

Au stade de développement 

Dans mon cycle de sprint, le testeur Q/A intervient après la phase de revue de code (code review).
Une fois que les développeurs ont fait leur MR (merge request), nous entrons dans ce que l’on appel la phase de Q/A (quality insurance).

A ce stade le testeur Q/A réalise les tests unitaires de chaque US.

A chaque daily ou à n’importe quel moment de la journée, le testeur Q/A vient m’informer de ses validations ou de ses doutes.

En général, si l’US ne comporte pas de bugs, il l’a passe directement en Done.

En revanche, s’il a rencontré des bugs, nous en discutons et nous faisons un débriefing rapide pour évaluer si les bugs rencontrés sont mineurs ou majeurs.

S’ils sont majeurs, l’US est rejetée et on la ré-assigne en TO DO au développeur en lui ajoutant un commentaire pour lui informer des bugs rencontrés.

PS: Je vous conseille, de toujours remettre les US (ou issues) ré-ouvertes en priorité 1 et tout en haut de la colonne TO DO.

La raison est simple, mieux vaut terminer une US entamée plutôt que d’en commencer une nouvelle.

Si les bugs sont mineurs, il se peut parfois que l’on passe l’US en Done et le testeur Q/A ou moi-même créons une nouvelle issue décrivant le bug rencontré dans l’US principale.

Ce bug mineur pourra être réglé plus tard mais l’important est de ne pas bloquer l’US principale et de la livrer la plus vite possible aux utilisateurs.

Extra

Une fois toutes les US testées et mergées, le testeur Q/A peut participer aux tests de régressions (Si vous ne savez pas ce que c’est, lisez ceci)

Dans mon cas, le testeur Q/A de ma squad, ne fait pas les tests de regressions et Smoke tests, car on a une team dédiée pour ça (la chance…).

A tous les stades :

Au delà de son intervention pré-sprint et pendant le sprint, le testeur Q/A teste régulièrement le produit en prod.

Il peut s’agir de test random ou de tests de bugs rapportés par le service support ou les utilisateurs.

Son rôle est de vérifier la nature du bug et de le documenter.

Enfin, en parallèle, quand il a du temps, à chaque évolution du produit, il est en charge d’implémenter des tests automatisés.

Ces tests ne sont pas utilisés partout et dépendent de la sophistication des entreprises par rapport à leur stratégie de qualité produit.

Dernière chose, ces tests nécessitent une grosse expertise d’outils spécifiques (Selenium, Silk Test, iMacro…) qui demandent une formation continue.

Et le product owner dans tout ça  ?

Vous devez donner les priorités

Comme je l’ai expliqué dans le paragraphe précédent, le testeur Q/A est et doit être  un membre à part entière de votre équipe.

Il participe à toutes les cérémonies et vous assure une source d’information supplémentaire sur une expertise précise.

Une fois les bugs détectés, vous devez vous assurer que la communication soit fluide pour être averti en temps réel.

A ce stade, ces bugs rentrent dans votre backlog ou alourdissent votre sprint et c’est à vous de les prioriser .

RAPPEL : Ce n’est pas au testeur Q/A de prioriser les bugs.
Pour vous donner des indications sur la nature du bug, le testeur Q/A peut donner une note de sévérité mais c’est toujours à vous de prioriser car c’est vous qui êtes en charge de l’agenda produit.  

Vous devez rester dans votre rôle 

Avoir un testeur Q/A dans son équipe ne veut pas dire zappez les tests.

Evidemment rien de nous empêche de tester le produit dès que vous avez un moment.

Nul besoin de vous rappeler également que vous devez avoir accès à tout moment sur votre mobile ou votre poste de travail à tous les environnements produits.

Cela doit etre naturel et même une obsession de tester le produit en permanence

Par ailleurs, votre oeil affuté ou votre vision marché doivent vous permettre de repérer des bugs ou des détails que nul autre ne voit.

Avec mon testeur Q/A nous sommes très complémentaires.
Lui voit des bugs ou des détails incroyables que l’on ne peut détecter qu’avec des tests poussés (stress tests) et moi je vois souvent des détails utilisateurs ou business.

Par ailleurs, encouragez toute votre équipe à tester le produit en permanence.

Développeurs, designers…. tout le monde à un regard différent qui apporte une vision 360 du produit et mène à l’excellence.

Conclusion, vous n’êtes jamais en charge des tests fonctionnels

Je ne le répèterai jamais assez, mais non ce n’est pas à vous de faire la recette.

Pour votre bien et pour la qualité du produit, recetter n’est pas une tâche à faire de votre métier.

Recetter est un métier à part entière qui demande une grosse expertise technique et une connaissance de process très précis.

Quelque soit les raisons évoquées, si vous recettez c’est que vous êtes dans un environnement agile dysfonctionnel (voir même pas agile du tout).

Parlez en à votre n+1.

Après discussion avec plusieurs PO, je pense que le problème majeur n’est pas un problème d’économie de bout de chandelle.

La majorité des organisations agiles ont assez de budget pour recruter au moins un poste supplémentaire à tout moment.

Le problème est que le poste de testeur Q/A est encore souvent méconnu dans certaines organisation (encore plus que le rôle du PO).

Cela me parait dingue vue de mon prisme mais je pense que le souci vient de là.

En recrutant un testeur Q/A, non seulement vous allez gagner en sérénité dans votre travail au quotidien mais votre organisation va gagner en productivité.

Avoir un testeur Q/A à ses côtés c’est s’assurer de livrer mieux et plus vite.

N’hésitez pas à commenter ce post pour me dire comment se déroule votre recette.

A bientôt,