Quels sont les différents cas particuliers à considérer pour bien appliquer l’ATDD manuelle en mode agile ?
Voyons quelques réponses à travers la suite de notre exemple.
Intégrer de nouvelles US INVEST qui étendent une fonctionnalité
Le sprint 2, par exemple, étend le modèle de la feature F3 (une seule US “s’authentifier de manière simple”, avec la saisie réussie de l’identifiant – mot de passe en au plus 3 tentatives), telle qu’elle a été exposée en sprint 1.
Rappel : F3 est une feature qui sera réalisée pour la release 1. En ce sens, elle est la première “version” de l’UC “s’authentifier”.
F3 pourrait dans une release ultérieure, et étant terminée, être “améliorée” par d’autres US ou des corrections d’US (qui pourraient être liées à une nouvelle feature).
Nous avons dans l’UC des US INVEST issues de plusieurs sprints. Elles représentent le produit à la fin du sprint 2 (comprenant les US INVEST du sprint 1 et les US INVEST du sprint 2).
- Chaque US nouvelle peut appliquer l’algorithme des tamis successifs
- L’UC peut aussi l’appliquer pour ses propres tests.
On voit immédiatement, en travaillant par “surlignage” sur le modèle graphique, les nouveautés amenées dans F3 (matérialisées en orange) et les parties non impactées. Ainsi :
- Suite à l’US « s’authentifier de manière simple », le test nominal (en bleu) et le test en échec après 3 tentatives (en noir) ont déjà été testés en sprint 1 (on peut donc les rejouer pour s’assurer de la non régression).
- Par contre, il manque 2 scénarios nouveaux c’est-à-dire les chemins (et en passant par les alternatives … s’il y en avait, ce qui n’est pas le cas) qui conduisent :
- Soit à une erreur en modifiant le mot de passe,
- Soit à un mot de passe modifié.
L’US INVEST (tâche) “s’authentifier de manière simple”, en elle-même, n’a pas été modifiée. Ses propres tests de régression n’ont pas de raison d’être rejoués puisque rien n’a été touché dans cette US.
Cependant, en intégration dans l’UC (avec le ticket F3 pour le sprint), on doit jouer les 2 scénarios existants de F3 comme des tests de régression pour ce UC.
Le testeur (le PO par exemple) peut vérifier manuellement que l’US existante, et non impactée, joue bien son rôle dans l’UC (une authentification réussie, une authentification en échec).
Intégrer de nouvelles US qui déstructurent une fonctionnalité
Prenons maintenant l’exemple dans la release 2. Le ticket représentant la feature F3 a été jugé terminé.
Cependant le PO propose la feature F10 comme un ticket intitulé “S’authentifier de manière forte”.
L’idée est maintenant de jouer une authentification plus sécurisée. Le produit aura donc l’ UC “S’authentifier” qui est le résultat des US “rescapées” de la release 1 et de nouvelles US de renforcement.
C’est l’UC qu’on modélise et non pas les seules US créées par la nouvelle feature F10.
Vous voyez que dans cet exemple (avec ici l’acteur client et le système qui intervient pour l’aider – cf. US4), l’UC a été sérieusement déstructurée (cf. les parties en violet). Dans ce cas il vaut mieux, à mon avis, chercher par l’algorithme des tamis successifs les nouveaux scénarios. Le travail est en effet extrêmement rapide grâce à l’algorithme, et comme le test sera manuel, les conséquences seront mineures en termes de productivité.
Il suffit alors, en taguant les évolutions agiles dans la table associée au modèle (“table des E/S”), de voir :
– Les scénarios qui n’ont aucun ticket du sprint : ce sont les scénarios de test pour les tests de régression
– Les scénarios qui passent par les tickets du sprint : ce sont les tests fonctionnels qui devront être exécutés pour valider l’intégration des nouveautés dans le produit.
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.
