Organisation usuelle des exigences
Le sujet des exigences et des tests de ces dernières est un sujet sensible mais nécessaire en Agile… Je l’ai d’ailleurs appris à la dure!
Sur le papier c’est assez simple, on a un produit. Ce produit est composé de macro fonctionnalités permettant de le définir. Ces macro-fonctionnalités sont les « epics », elles sont composées de « Feature » qui sont des éléments plus petits mais trop grand pour être INVEST et donc une US (User Story), l’élément élémentaire des produits Agile.
A noter: il existe d’autres dénomination, je pense notamment à US/Epic/initiatives.
Une architecture d’un produit Agile ressemble donc à cela:
L’élément feature n’est pas toujours présent, le passage se fait parfois directement de l’épique à l’US.
Pour rappel, une US INVEST veut dire:
- I: indépendante, ne compte pas sur un autre élément qui doit être développé en même temps ou avant
- N: négociable, il est possible de discuter autour de cet élément, de son fonctionnement, de son implémentation…
- V: valeur, cet élément a une valeur métier
- E: estimable, il est possible d’estimer un effort pour développer cet US
- S: petit (small), cet élément peut être développer sur 1 incrément (sprint en scrum)
- T: testable, on peut tester la fonctionnalité.
Vous pouvez remarquer qu’il existe des éléments non testables qui ont pourtant de la valeur. On parle alors de Technical Story (TS) ou, comme SAFe, d’enablers. Une feature peut être composée de ces enablers ou TS.
Maintenant que l’organisation des exigences est connue il est temps d’organiser ses tests!
Le test des exigences Agile
Le test des nouvelles US est assez simple en terme d’exigence. L’équipe doit valider en profondeur (à travers des tests de validation) le comportement de la nouvelle fonctionnalité. Les tests dédiés (qui ne seront, pour la plupart, pas réutilisés) sont liés à une US spécifique.
Lorsque cette US est implémentée il est important de mettre à jour sa campagne de régression et généralement de l’incrémentée de quelques tests conçus et écrits pour cette US.
Un problème se présente alors. Notre régression est composée de tests d’US. Ces mêmes US sont finies et donc non maintenues. Par ailleurs le produit continue à évoluer avec de nouvelles US qui vont annuler ou modifier l’intégralité ou une partie des US qui ont déjà été développée. Cela entraîne à moyen terme de gros problème quant à notre patrimoine de test car il est lié au feuilles d’un arbre d’exigence qui les a potentiellement perdues et remplacées!
Arrivant à ce constat lors d’une de mes missions il y a maintenant quelques années j’ai du retravailler totalement mon référentiel d’exigence afin d’avoir une meilleure vision du produit mais surtout une vision qui reste à jour!
Les faits étaient implacable: impossible de continuer à garder comme référentiel de base les US. Nous avons donc choisi de restructurer notre patrimoine et avons adopté une vue plus haut niveau: les épiques (cela aurait pu être les features).
Les tests de validations restent attachés aux US. Les tests de régression, maintenus, ont alors été liés à des épiques.
Conclusion
Les US sont des éléments de travail éphémères dans la construction d’un produit. Elles sont essentielles dans le travail quotidien mais ne peuvent servir de base pour un référentiel pérenne d’exigences et donc de test.
Afin d’assurer cette vie sur le long terme il est essentiel d’utiliser un référentiel d’exigence produit qui reste vivant. Cela peut passer par les features, les épiques, de la documentation ou tout autre support mais l’essentiel est d’avoir une base solide qui permette de bien comprendre le produit et qui serve de base à notre campagne de régression.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
