Press "Enter" to skip to content

Once upon a time, le PO Testeur

Aujourd’hui, la notion de qualité dans les applications délivrées prend de plus en plus d’ampleur dans le monde numérique. Cependant, si les hiérarchies arrivent à bien identifier les coûts pour mettre en place une certaine qualité, elles n’arrivent pas forcément à faire de même pour les gains que cela va apporter. Les dirigeants vont donc mesurer les coûts et les contrôler le plus possible. Le plus souvent, ces restrictions vont empêcher de mettre en place un service qualité pleinement efficace, et donc empêcher le but final qu’est le produit de qualité.

Une de ces restrictions, que j’ai pu constater plusieurs fois par moi-même, est celle de la double casquette PO et chargé des tests fonctionnels. Ces deux rôles sont selon moi incompatibles sur un même projet. D’une part, leurs charges de travail individuelles sont trop importantes pour assumer un deuxième rôle. Sur un projet, les missions de ces 2 profils s’effectuent correctement si on s’y consacre à temps plein. De plus, les missions demandées, les profils, et les points de vue sont complémentaires et se challengent l’un l’autre.

Dans cet article, on pourra également assimiler le rôle du PO du cadre Scrum au rôle de Business Analyst dans d’autres méthodes.

1) Deux rôles qui vont se challenger

En effet, les missions de ces deux acteurs sont fondamentalement différentes, mais surtout complémentaires l’une de l’autre. Le PO va porter la vision du produit et alimenter le backlog, la liste des fonctionnalités qu’on envisage d’intégrer dans le produit. Il va toujours chercher à ajouter de la valeur au produit. Le chargé des tests, lui, va concentrer son attention sur la qualité et la cohérence de l’application. J’entends par là qu’il est le dernier maillon qui sera en mesure de relever une anomalie, qu’il s’agisse d’un bug ou d’un défaut de conception, avant la livraison. Il va donc challenger la vision que transmet le PO, dans le but de l’aiguiser et de la préciser. La qualité va donc être indissociable de la valeur que le PO souhaite ajouter au produit.

Le PO porte la vision du produit, le testeur vérifie sa cohérence et son bon fonctionnement.

Chronologiquement, dans un Sprint, la première mission du testeur fonctionnel va être de tester les hypothèses et attentes des User Stories (US) présentées par le PO. En effet, lorsque ce dernier présente les US, l’équipe va les analyser, demander des informations complémentaires si besoin, et les challenger si elle a des idées pour la compléter. L’équipe va également vérifier que le besoin exprimé dans l’US est réalisable techniquement, que l’implémentation ne va pas déséquilibrer le fonctionnement de l’application, et évaluer la testabilité de la fonctionnalité ainsi que la couverture de tests nécessaire.

Les personnes en charge des tests sur le produit sont celles qui le parcourent le plus. En effet, déjà lors de la rédaction des cas de test, les testeurs vont arpenter l’application afin de s’assurer que les cas de tests rédigés correspondent bien au fonctionnement de l’application. Ensuite, l’utilisation du produit est bien sûr indispensable pour valider l’exécution des scénarios de tests. Ainsi, les testeurs vont avoir une approche et une expertise de l’application bien particulière et différente de celle du PO, et par conséquent ils auront une sensibilité différente sur la cohérence des US présentées avec le produit. Dans ce cas-là, la notion de “PO testeur” va donc empêcher une complémentarité de point de vue. Le produit risque finalement de perdre une certaine précision et une certaine cohérence dans l’application.

2) Deux rôles, Deux points de vue

Lorsque le PO rédige une US, il va généralement être responsable des critères d’acceptation. Ces critères d’acceptation sont une liste de conditions que le développement devra vérifier pour que l’US soit acceptée. Ceci en plus des autres éléments de la Definition of Done, un document rédigé par la Scrum Team détaillant les points techniques et fonctionnels généraux pour qu’une US puisse être validée. Il doit donc entrevoir au maximum les implications que peuvent avoir les évolutions sur le reste de l’application, afin d’éviter de la déstabiliser. Pour prendre un exemple concret, imaginons une application où nous allons avoir une liste d’objets qui peuvent être dans certains états : en service, en sous-régime, hors-service. Si nous souhaitons ajouter un nouvel état dans la liste des états disponibles pour cet objet, il faut prendre en compte un certain nombre de conséquences. En effet, il faut rajouter cet état dans les différentes recherches sur ce type d’objet. Il faut donc penser à rajouter un filtre sur cet état dans ces recherches. Il en va de même dans un éventuel reporting ou dans chaque section faisant appel à cet objet.

Le risque des critères d’acceptation est de les considérer comme exhaustifs. Ils ne représenteront jamais que ce que le PO aura envisagé. Il ne peut être considéré comme le super-héros, sans qui l’application s’effondrerait. Il peut, et même il va oublier des impacts dans la conception d’une fonctionnalité. C’est notamment là que le fait de porter la vision du produit et de l’expliquer auprès de l’équipe prend son sens : s’il essaye de penser à tout et d’être exhaustif dans la conception de sa fonctionnalité, il privera l’équipe d’un sens d’initiative précieux, qui sera essentiel pour permettre à l’équipe d’assumer pleinement son rôle. L’expertise collective ainsi créée sera beaucoup plus importante que l’expertise du PO seul. Finalement, le but du PO est plus d’être compris, que d’être complet. Avec une bonne compréhension, les testeurs et les développeurs vont eux-mêmes compléter la conception des fonctionnalités selon une vision entièrement partagée entre les différents acteurs.

Le but du PO est plus d’être compris, que d’être complet.

La mentalité du testeur requiert quant à elle un côté exploratoire en plus. Il va, dans ses tests, réaliser diverses combinaisons afin de couvrir un plus large périmètre en quelques cas de test sur une fonctionnalité. Cette manière de rédiger des cas de tests et de les exécuter permet de sortir de l’utilisation prévue qui est faite de l’application. Ainsi, les cas d’utilisation non prévus par le PO peuvent être couverts et gérés.

On a donc encore 2 comportements qui sont autant complémentaires qu’impossible à combiner pour un seul produit. Alors que le premier va imaginer le fonctionnement et l’utilisation d’un produit, le second va vérifier que les dysfonctionnements ou que les mauvais cas d’utilisations sont couverts.

3) Arbitrage et neutralité du PO

Beaucoup d’équipes font le choix d’inclure au rôle du PO l’arbitrage des anomalies rencontrées. Ce n’est pas une règle absolue, d’autres profils dans l’équipe peuvent endosser cette responsabilité, mais un choix courant. Le profil le plus adapté pour déterminer si une anomalie relève plutôt du bug ou de l’évolution reste le testeur. Le PO va quant à lui prioriser cette anomalie en fonction de sa valeur et de sa criticité, dans le cas d’un bug. Certains bugs ne seront volontairement pas corrigés, ou du moins, pas dans l’immédiat. En effet, ces bugs peuvent représenter un risque assez limité, soit par la faible probabilité qu’ils se déclenchent, soit par un très léger impact dans le fonctionnement du logiciel. A l’inverse, certaines évolutions peuvent être urgentes à réaliser, de par les attentes de certains clients ou des autres parties prenantes.

La complexité du rôle de PO relève notamment de cette difficulté à maintenir la direction d’un produit face à la pression des toutes les parties prenantes sur le produit, qu’elles soient interne ou externe. S’il assume également le rôle d’une des autres parties prenantes, il n’aura plus la neutralité nécessaire pour maintenir le cap. Cela entrainera finalement un déséquilibre entre les différents acteurs de l’équipe et génèrera des tensions.

4) Neutralité du testeur

La dernière incompatibilité pour combiner les deux casquettes sur un même projet est, selon moi, la plus subtile et la plus perverse :

Le PO subit la pression de clients ou des investisseurs, qu’ils soient internes ou externes. Lors de la conception de nouvelles fonctionnalités, il peut être amené à faire passer certains points pour entretenir la satisfaction des acteurs extérieurs à l’équipe. Dans ce cas, l’erreur étant humaine, il peut entrer ainsi en incohérence avec le reste de son application. Il est alors impossible d’envisager un rôle de testeur pour lui. En effet, une personne qui imagine une fonctionnalité va avoir du mal à admettre qu’elle a pu avoir des défauts dans sa conception. A partir de là, il y a plusieurs possibilités.

Le plus couramment, le PO va s’apercevoir de son erreur et la rectifier. Soit en créant des évolutions, soit en repensant complètement la fonctionnalité si elle est mal conçue dans sa globalité. Il arrivera cependant très souvent qu’il ne s’aperçoive pas de son erreur. Dans ce cas il pourrait remonter un bug au lieu d’une évolution, et comme dit précédemment, il n’a plus la neutralité pour définir clairement s’il s’agit bien de l’un ou de l’autre.

Plus tôt est détecté le défaut, moins il est coûteux à corriger

Enfin, le pire qu’il puisse faire pourrait être d’ignorer inconsciemment une incohérence rencontrée. Comme cela a pu être évoqué précédemment, le PO est soumis à des contraintes temporelles et financières. En tant que testeur, ces contraintes pourraient le pousser à « décider inconsciemment » de ne pas relever une anomalie, surtout si elle serait due à un défaut de conception. Ceci dans le but d’éviter un retard de livraison, par exemple. Cette anomalie peut alors provoquer une instabilité du logiciel. Selon l’utilisation qui sera faite en production chez un client, c’est un défaut qui pourrait ralentir ou empêcher l’utilisation du logiciel par les utilisateurs. Ainsi, les conséquences financières et temporelles deviennent plus importantes qu’une correction en amont. En effet, toute l’équipe serait alors mobilisée pour mettre en place un patch en urgence. Or il est connu que ces patchs faits dans la précipitation prennent du temps et entament la motivation d’une équipe.

Conclusion

La qualité d’un produit est garantie notamment par un équilibre entre les différents acteurs et le rôle qu’ils jouent dans sa réalisation. La bonne réalisation des missions d’un rôle dépend de celles des autres rôles. Il est donc crucial que chacun se concentre sur son rôle, sans assumer une charge de travail supplémentaire, mettant ainsi en péril l’équilibre entre les équipes, ainsi que l’équilibre du produit. Cependant, ça n’enlève pas au PO son devoir de validation de la bonne compréhension et de la bonne réalisation des US, notamment par l’utilisation fréquente de son application.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top