Tester c’est douter !

Tester c’est douter !

Et là, juste au titre de cet article, j’entends les QA, les devops, les software craftsmen et tous les professionnels du test et même tous les professionnels du développement de produit s’outrer et ils auraient raison, mais il n’empêche : Tester c’est douter.

 

Crédit Image : Commitstrip.com

 

J’entends souvent, je l’ai entendu encore pas plus tard qu’hier, que le Product Owner est le recetteur naturel des projets Agiles, qu’il connaît parfaitement le métier etc.

Après tout, le PO, c’est un ancien AMOA, c’est quasiment pareil, l’AMOA recettait, pourquoi le PO ne ferait pas pareil ? Hein ?

Non ?

Et bien non, un Product Owner qui teste, c’est un Product Owner qui doute, il doute de la qualité du produit, il doute de l’équipe de développement. Il rentre dans ses attributions de valider les User Stories, mais pas ce qu’on appelle de la recette, c’est l’équipe de développement qui s’en occupe. Faire des tests avec des utilisateurs, pas de soucis, encore que des spécialistes de l’UX le feront surement bien mieux. Mais vérifier que le bouton “valider” crée bien un lead ou que quand on lance le site sur tablette il n’y a pas de problème d’affichage, et bien non.

 

Un Product Owner qui teste, c’est un Product Owner qui doute.

 

L’équipe de développement a pour mission de livrer un produit potentiellement livrable à l’issu du sprint. Il me paraît du coup assez inconcevable de livrer un produit qui n’est pas testé du tout. Dans ce cas, il semble évident que l’équipe de développement doit avoir les compétences pour tester l’application, y compris les compétences fonctionnelles et pas seulement les compétences techniques.

Je pense que l’erreur vient essentiellement de ce terme d’ailleurs : “Equipe de développement”. Ceux qui ont lu le Scrum Guide en diagonale ou ceux qui ne l’ont pas relu depuis 2011 s’imaginent que cette équipe est composée uniquement de développeurs (Développement = Développeurs), alors qu’en vérité, l’équipe de développement doit posséder toutes les compétences nécessaires à la réalisation du développement du produit.

 

 

Dans la plupart des structures dans lesquelles j’ai travaillé et qui avaient un long passif “Cycle en V”, le premier réflexe du management a souvent été d’imposer au Product Owner une phase de recette avant la mise en production “pour se rassurer”, une fois le MVP prêt à être mis en production.

Rappelons que le rôle du Product Owner dans le Scrum Guide est en résumé ultime “celui qui maximise la valeur du produit”. De mon point de vue, le Product Owner fonctionne en 2 temps, sur l’avenir et sur le présent. Sur l’avenir, il prépare les éléments de son backlog pour les itérations suivantes avec toutes les parties prenantes (et l’équipe fait de mon point de vue partie de ce groupe-là aussi) et sur le présent, il travaille au quotidien auprès de l’équipe de développement durant toute la durée du sprint pour porter la vision et l’aider dans ses choix. Il n’intervient sur un temps passé que pour préparer l’avenir, il n’est pas l’inspecteur des travaux finis qu’on lui demande souvent d’être.

 

Sur une User Story en particulier, il validera, c’est à dire qu’il s’assurera que l’ensemble des critères d’acceptance sont valides. Par la suite il se servira de tous les outils mis en place pour valider “avec les utilisateurs” que la User Story répondait bien au besoin.

Vous l’aurez compris je ne remets pas en cause la recette et les tests bien au contraire, en fait je ne remets pas en cause que la personne qui est Product Owner recette… par contre quand il recette, il est membre de l’équipe de développement et n’est plus PO et ça demande une sacré gymnastique intellectuelle !

 

Ce qui n’est pas sans rappeler le Scrum Master qui développe également et qui doit à la fois être neutre et ne pas l’être !

 

 

Share this story:

2 Comments

  1. En agile, la qualité concerne tout le monde. Le test n’est réservé à une categorie de personne. On demande aux devs de faire du test, et c’est normal. On doit aussi sensibiliser les PO au test, notamment lorsqu’ils decrivent les AC. Mieux, ils doivent etre capable de decrire les AC sous forme d’AT, ce qui va simplifier le travaille de tout le monde.
    Bref, pas du tout en phase avec ce post, qui a tendance a recréer des silos de responsabilité.

    1. Bonjour Cyril,

      Merci pour ton retour, je pense que du coup ne pas avoir porté exactement le message que je voulais, car nous sommes d’accord.
      Car mon propos n’était pas de dire que le Product Owner ne teste pas, mais de dire que c’est de la responsabilité de tous que de réussir à produire un logiciel de qualité et surtout que dans la plupart des organisations pour laquelle j’ai travaillé, l’équipe de développement ne testait pas ou presque pas car c’était “au product owner de le faire”.
      Il y a cependant dans Scrum (je pars juste du Scrum Guide pour le dire) un silos de responsabilité entre la dev team, le scrum master et le product owner, mais cela reste sur les rôles et pas sur les gens qui les tiennent.

      cdlt

Leave a Reply

Your email address will not be published. Required fields are marked *