PO et testeur… C’est possible?

La réponse peut paraître simple… Surtout lorsque l’on regarde ma mission actuelle chez Orange ! Néanmoins cumuler ces 2 casquettes soulève au moins 1 problème majeur .

Problématique :

Le PO représente le métier et est responsable des tests d’acceptance (Niveau 4) alors que le testeur s’occupe (et généralement exécute) les tests systèmes (Niveau 3) => Une seule et même personne peut-elle exécuter ces 2 types de tests ? Quel est l’impact sur la qualité de l’application si c’est le cas ?

Lorsque je suis arrivé sur ma mission, il était pour moi hors de question que je m’occupe des 2 niveaux de tests car je fais une distinction très nette entre ces 2 niveaux. J’appréhendais également des impacts négatifs sur la qualité de l’application notamment en limitant le nombre de regards sur cette dernière…

Etant le seul « testeur » de métier de mon équipe mais aussi le PO, représentant du client, je ne pouvais pas permettre de laisser une faille de qualité équivalente.

Solution choisie :

J’ai profité de l’agilité et de ce qu’elle permet => J’ai délégué!

Je me suis concentré sur la mise en place des processus, la conception des tests et la partie du travail de PO (l’écriture des User Story, l’exécution des tests de validation, faire le lien avec le client).

J’ai donc laissé aux « développeurs » certaines activités du test: l’exécution et la maintenance des tests, mais aussi leur automatisation et la gestion de cette dernière. Ces activités, en plus d’être les parties rentrant en conflit avec le rôle de PO sont les parties où les connaissances d’un testeur ont le moins de valeur ajoutée.

Mise en place de la solution :

Tout d’abord il a fallu travailler avec les membres de l’équipe et le marketing afin de connaitre les besoins du projet et l’équipe qui devait le développer.

J’ai alors pu travailler sur la mise en place de processus de validation des User Stories :

·        Les critères d’acceptance mais aussi le workflow de validation, quels tests ? quand ? pourquoi ?…

Suite à la validation par l’ensemble de l’équipe une matrice « RACI » pour les tâches du test a été validée. Toujours en échangeant avec l’équipe nous sommes tombés d’accord sur plusieurs points :

·        Je m’occupe de l’exécution des tests d’acceptance

·        Je m’occupe de de l’écriture et de la conception des tests

·        Je m’occupe de la sélection des tests à automatiser, maintenir et leur affectation aux différentes campagnes de tests.

·        L’équipe de développement s’occupe de l’exécution des tests

·        L’équipe de développement s’occupe de l’envoi des bilans de recette

·        L’équipe de développement s’occupe de l’automatisation des tests

·        L’équipe de développement forme 1 back up pour l’automatisation des tests car 1 seul pouvait avait la connaissance au début du projet)

Résultats obtenus:

Le projet n’est pas fini (en Scrum un logiciel continue d’évoluer) mais se déroule normalement et… la qualité est au rendez-vous ! L’entente dans l’équipe est bonne.

De plus le back up qui a été formé pour l’automatisation des tests est maintenant à plein temps sur les tests et souhaite continuer à travailler dans l’automatisation des tests.

Enfin, tout ce qui a été mis en place au départ est resté, voire s’est amélioré au fur et à mesure du projet. Les développeurs sont devenus force de proposition, développe certains tests, automatisent d’eux même des tests liés à des bugs afin de ne pas les réintroduire… toute l’équipe est investie dans la qualité.

Je tiens également à ajouter que les retours de l’équipe sont très bons. Les développeurs sont très satisfaits de travailler dans ces conditions et sont très satisfaits de la qualité et de la présence des tests car cela leur fait gagner beaucoup de temps (très peu de régressions).

Conclusion :

La solution mise en place a parfaitement fonctionnée. Selon moi la clé n’est pas uniquement la qualité des processus (on aurait pu en utiliser d’autres également pertinent) mais bien la communication et la mobilisation de l’ensemble de l’équipe sur le sujet de la qualité.

On a réussi, en tant qu’équipe, à bien mettre en place les principes du Scrum en mettant en avant l’humain et le dialogue.

Le cumul des casquettes de PO et testeur a donc fonctionné… En faisant, évidemment, quelques adaptations.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles