Après quatre années passées en tant que Product Owner au sein d’une grande DSI, jonglant entre priorités, users stories et sprints, je pensais bien connaître les rouages du développement produit. Mais c’était sans compter sur la découverte d’un territoire jusqu’alors inexploré : le monde des tests.
Au début, j’y ai mis les pieds avec prudence, un peu comme un joueur qui découvre une nouvelle zone de jeu sans en connaître les règles. Ce domaine m’était presque totalement étranger. N’ayant pas de formation technique, j’ai dû partir en quête de savoir, échangeant avec les développeurs, me plongeant dans des recherches (Lien 1, Lien 2, Lien 3, Lien 4, Lien 5) et en expérimentant moi-même. Peu à peu, j’ai compris que les tests n’étaient pas un simple passage obligé en fin de développement, mais une véritable clé pour garantir un produit de qualité, stable et performant.
Quête principale : Trouver le Graal d’un produit fiable
Mon premier apprentissage a été l’importance des tests fonctionnels, ceux qui touchent directement à mon rôle. J’ai mis en place un processus de validation dès la livraison en environnement de test et élaboré un cahier de recette pour impliquer les parties prenantes. Ce précieux grimoire m’a permis d’affiner les critères d’acceptation des User Stories et d’assurer que chaque fonctionnalité réponde exactement aux besoins exprimés.
Mais mon rôle ne s’arrêtait pas là. J’ai compris qu’un PO devait voir les tests comme un levier d’amélioration continue. J’ai donc intégré les tests dans les démonstrations de fin de sprint, et je me suis attaché à différencier deux armes redoutables :
- Les tests manuels, essentiels pour valider l’expérience utilisateur et détecter des subtilités qu’une machine ne verrait pas.
- Les tests automatisés, véritables gardiens qui assurent une régression limitée et une stabilité accrue du produit.
Grâce à cette approche, j’ai amélioré ma connaissance du produit. Tester les fonctionnalités m’a permis de les comprendre en profondeur et d’anticiper les difficultés des utilisateurs. La rédaction du cahier de recette m’a aidé à mieux formuler les User Stories en prenant plus de recul lors de leur rédaction et à prévoir d’éventuels blocages en amont.
Quête secondaire : Intégrer les tests dans l’Agilité
Dans la quête du développement itératif, l'équipe a dû faire face à un adversaire redoutable : le rythme effréné des tests. Pour le vaincre, ils ont forgé une arme puissante : l'automatisation de la non-régression. L’outil Selenium a été utilisé pour tester le front comportant les fonctionnalités existantes. Mais l'équipe savait qu'aucun sortilège ne remplace l'œil humain. Des tests manuels de NR ont donc été mis en place, validant la cohérence de chaque incrément. Pour une approche itérative de la recette, celle-ci a été intégrée aux User Stories.
Notamment grâce à l'astuce des "Tres Amigos" qui réunit PO, développement et qualité : Ensemble, ils ont conçu chaque nouvelle fonctionnalité en tenant compte des tests dès la phase de conception, assurant une compréhension commune de l'objectif de l'User Story.
Boss final : La mise en production, l’épreuve ultime
Mais chaque quête mène à un boss final : la mise en production. Ce moment tant redouté où le produit quitte les terres familières de l’environnement de test pour affronter la réalité des utilisateurs. Avant chaque livraison, nous avons mis en place une véritable stratégie de bataille :
- Démonstration de la fonctionnalité pour valider que le développement correspond bien au besoin.
- Test manuel des évolutions, pour traquer les derniers ajustements nécessaires.
- Test de non-régression, afin de s’assurer que les fonctionnalités principales restent intactes.
- Tests d’intégration et de performances afin de garantir le comportement du produit lors de l'intégration dans le système et de valider sa performance dans des conditions d'utilisation réelle.
- Documentation et partage des résultats avec les équipes concernées pour garantir une traçabilité optimale.
Nous avons également utilisé Xray pour structurer et suivre nos campagnes de tests, un outil qui s’est révélé indispensable lorsque la tâche de test était répartie sur plusieurs personnes. Grâce à ces pratiques, nous avons drastiquement réduit le taux de bugs en production et amélioré la satisfaction des utilisateurs.
Et après ? L’aventure continue !
Cette plongée dans l’univers des tests a transformé ma vision du rôle de Product Owner. J’ai non seulement renforcé ma collaboration avec l’équipe technique, mais j’ai aussi gagné en autonomie et en compréhension du produit.
Les tests ne sont pas une simple validation, mais une véritable arme pour garantir un produit fiable et évolutif. En les intégrant dès la conception, on assure une meilleure maintenabilité du code et une expérience utilisateur optimale. En tant que PO, j’ai désormais la conviction que la qualité n’est pas une étape finale, mais un état d’esprit à adopter tout au long du développement.
L’aventure ne fait que commencer, et chaque sprint apporte son lot de défis. Prêt à embarquer pour le prochain niveau ?
“Un test pour les couvrir tous, un test pour les tracer, un test pour les automatiser et dans la qualité, livrer” - Tiffany, Product Owner qui croit en l’importance du test.
