Considérons maintenant deux exemples où une tâche est touchée par des modifications de spécifications internes (changements d’ergonomie, règles de gestion, … qui auraient dû être pris en compte au sein de l’US INVEST initiale). Elles ne peuvent pas être qualifiées d’INVEST … Les US étant déjà de tailles très faibles, le PO ne peut qualifier ces détails de “fonctionnalité”. Il pourrait dire, par analogie à la physique, que ce sont juste des particules élémentaires d’un atome de la réalisation informatique.
Rappel : Nous conseillons donc d’utiliser un ticket adapté (ex: correction d’US).
Scénarios de test et de régression pour une US
La stratégie de génération de test dépend de vos choix en matière d’organisation des tests : avez-vous choisi, une fois les tests identifiés, de les automatiser ou non ?
Dans le cas où la réponse est positive (nous avons un référentiel de tests automatisés), alors nous préconisons de :
- Revoir le tableau des exigences et scénarios de l’UC pour :
- Identifier les scénarios impactés par au moins une correction : ce seront des tests “à jeter”, donc à effacer de la table de décision.
- De fait ceux restant intègrent les scénarios de tests pour analyser la régression
2. Repartir alors de cet ensemble de scénarios, et faire le bilan des couvertures des différents tamis.
3. Reprendre alors l’algorithme pour compléter les tests.
Dans le cas où nous n’utilisons pas de tests automatisés (mais nous faisons des tests manuels pour chaque sprint), alors l’idée est tout simplement, comme pour les tests des fonctionnalités :
- Appliquer l’algorithme des tamis successifs
- Taguer les scénarios (SNR ou Sx), selon que les scénarios exécutent au moins une fois une correction d’US due au sprint, ou non.
La méthode est donc extrêmement rapide et simple.
Nous allons voir que le cas de tests automatisés implique (voir l’étape 1 expliquée ci-dessus) une analyse de régression. Montrons donc que cette situation complexifie le travail.
Tester des modifications impactantes mais internes à une US INVEST
Supposons que l’US INVEST « Évaluer le risque client” (“tâche” modélisée dans l’UC s’authentifier) doit désormais, par un ticket de correction d’US, prendre 3 valeurs (au lieu de 2, à savoir vert ou rouge) : Vert, orange et rouge. Il va donc falloir retester la tâche par l’algorithme, en supposant des tests automatisés d’US existants.
Par conséquent, nous avons les points suivants à traiter :
- Dans la documentation les règles d’attribution changent (ex: les 2 règles “vert pour une note de 1 à 3 et rouge de 4 à 10”, sont modifiées “vert pour 1 à 2, orange de 3 à 6”. D’autre part une règle est ajoutée “rouge de 7 à 10”).
Ces règles doivent être vérifiées. Le scénario de test orange est ainsi à construire … et les tests vert et rouge à modifier (même si les scénarios de test sont récupérables, les valeurs limites ont changées).
- Et les tests de l’UC sont à revoir pour intégrer les effets liés au risque de l’introduction de la nouvelle valeur “orange” ! Là encore les scénarios de test avec passage dans le vert et le rouge peuvent être repris, mais pas forcément les données utilisées.
Supposons que l’UC2 avant le sprint (empilage des tickets pour évaluer le risque client et fixant la fonctionnalité du produit à l’instant t) était composé de 2 US INVEST :
- US 10 : Tâche pour “Calculer le risque” (de 1 à 10)
- US 23 : Tâche “Affecter le statut” (vert, orange ou rouge).
On constate que seule la 2ème US est touchée par la modification puisque ce sont les règles d’affectation de statut qui changent. Les corrections sont donc demandées par un ticket “Correction d’US – 12”
En noir, ci-dessous, la table BML de la tâche existante dans le référentiel d’exigences et, en rouge, les modifications de spécifications souhaitées (Correction d’US – 12).
En vert, les modifications dans les tests (scénarios valorisés) et/ou tests dans un scénario nouveau.
Bilan : on constate un poids faible de la régression potentielle (1 / 3). Cela traduit le fait que les modifications souhaitées sont, tout compte fait, majeures, laissant peu de sujets existants encore valables.
- En effet seuls 2 tests de la tâche restent toujours d’actualité (a-t-on de la régression ?), tandis que 4 nouveaux tests sont à faire pour la correction “Correction d’US – 12”.
- Les tests de l’UC ont le même constat (puisqu’il faut avoir calculé le risque pour affecter le statut).
- Par contre pour la macro-fonctionnalité “Gérer son compte”, un seul scénario est à créer (cas orange) et les 2 scénarios existant peuvent être repris (avec les tests qui ne changent pas).
On constate, sur cet exemple très simple, que l’analyse de régression n’est pas évidente et reste une activité exigeant de la réflexion humaine (enfin, pour l’instant !).
Remarque :
Cet exemple montre qu’en fait les US INVEST “Calculer le risque” et “Affecter le statut” sont … très dépendantes. La question mérite d’être posée : si on teste la 1ère US dans un sprint indépendamment de la 2ème, n’a-t-on pas intérêt à tester l’UC englobante (Évaluer le risque client) dans son ensemble, notamment la 2ème US, pour profiter de la 1ere US réalisée ? L’agilité n’impose-t-elle pas d’aller au plus vite ?
On retiendra que les tests d’une US peuvent demander l’exécution d’une autre US déjà vérifiée. Cela facilite grandement la mise en œuvre du test en disposant, de manière simple, des données utiles. Cela n’est pas choquant pourvu que l’/les US soit/soient déjà testée(s) et que cela soit indiqué dans les pré-conditions nécessaires aux tests de l’US considérée.
Tester des modifications peu impactantes et internes à une US INVEST
Si une correction d’ergonomie a été demandée (ex : changer une taille de police, ajout d’un logo, modification de couleurs …) l’analyse de régression sur les scénarios de test existants est simple.
Illustrons le sujet par l’exemple de l’US “S’authentifier de manière simple”, en changeant le texte d’un message d’erreur.
On reprend le tableau existant, en modifiant uniquement la règle demandée (et en conservant les tests existants).
Le message d’erreur E1 devient E’1. Dès lors, on voit immédiatement les scénarios de test :
- Jouer le scénario 2 pour vérifier la prise en compte de la demande
- Jouer les scénarios 1 et 3 comme tests de régression qui, ici, s’avèrent avoir un poids plus important (2/3 sur la campagne de cette US).
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
