Les scénarios de test sont identifiés grâce à l’algorithme des tamis successifs. Reste à “valoriser” les scénarios de test (critères d’acceptation avec leurs valeurs intermédiaires) pour obtenir les “tests” de l’US.
Principe le plus courant de valorisation des données
On pourra s’attacher à analyser chaque affirmation de chaque RG.
Il existe, là encore, plusieurs solutions progressives pour affecter des valeurs aux données en jeu.
1- Tester les affirmations BML avec une valeur représentative
Ex1 :
QUAND la couleur de la tâche est fondamentale (valeurs : blanc, noir, rouge, jaune, OU bleu)
ALORS la tâche est affichée
Cas de test 1 : la RG est testée au moins une fois avec la couleur fondamentale la plus courante : le noir
Ex2 :
QUAND X>=0 et Y>0 ALORS Z = X/Y * A
Rappel : X et Y sont des naturels, X est compris entre 1 et 999 compris et Y entre 1 et 10 compris, A est soit compris entre 0 et 3, soit entre 5 et 10, Z est un réel arrondi à un chiffre après la virgule
Cas de Test 1 pour l’affirmation X>=0 et Y>0 de l’unique condition : X=100, Y=500 cas nominal (et A vaut 6, valeur la plus courante)
2. Tests représentatifs des observations aux limites
Ex2 :
QUAND X>=0 et Y>0 ALORS Z=X/Y * A
rappel : X et Y naturels, X est compris entre 1 et 999 compris et Y entre 1 et 10 compris, A est soit compris entre (1 et 3), soit entre (5 et 10) et Z réel avec un chiffre après la virgule
Cas de Test 2 : X=1, Y=10, A = 1 cas limite basse pour Z (Z=0,1)
Cas de test 3 : X=999 et Y=1, A = 10 cas limite haute pour Z (Z=9990)
3. Tests représentatifs de chaque frontière de donnée au moins une fois
Ex2 :
QUAND X>=0 et Y>0 ALORS Z=X/Y * A
rappel : X et Y naturels, X est compris entre 0 et 999 compris et Y entre 1 et 10 compris, A est soit compris entre (1 et 3), soit entre (5 et 10) et Z réel avec un chiffre après la virgule
Si X et Y ont déjà testé au moins une fois leurs limites, A n’a pas testé toutes ses “frontières internes”.
Cas de Test 4 (par exemple) : X=1, Y=10, A = 3
Cas de test 5 (par exemple) : X=999 et Y=1, A= 5
Autres techniques
Ajoutons à ces recommandations, deux autres conseils (même si, probablement, j’oublie encore certaines heuristiques …).
- Cas d’affirmations se répétant dans plusieurs RG
Il existe au moins une technique plus simple, dans le cas où une affirmation se répète dans plusieurs RG. Dans ce contexte, on ne regarde pas immédiatement chaque affirmation de chaque RG, mais, dans un premier temps, on s’assure que :
- Chaque affirmation est valorisée
- Chaque donnée spécifique de l’affirmation (représentative, limite ou frontière) est testée au moins une fois.
- Différentier conditions et observations
Une autre technique, permettant de rendre les tests progressifs, consiste à distinguer les affirmations dans les conditions et les affirmations dans les observations.
Un objectif de couverture peut, en effet, se focaliser d’abord sur les données spécifiques de résultats à observer, puis sur les données de conditions qu’il faudrait encore ajouter.
Remarque :
Les données mises en avant dans les techniques de valorisation sont celles spécifiques aux scénarios de test.
Il faut prendre en compte, pour que le scénario de test soit complètement instancié, au moins deux autres notions qui complètent les données à mettre en oeuvre :
- Les données pré-requises (ex: prendre un client admissible au crédit, entre 18 et 25 ans, étudiant, etc.)
- Certaines données importantes à saisir (les autres n’ayant pas d’influence et étant laissées sous la responsabilité du concepteur de test ATDD en mode manuel) pour la ré-utilisation ultérieure du test (ex: saisir une demande de crédit à 100 euros/mois, sachant que le client a un loyer de 400 euros/mois, un revenu personnel de 600 euros/mois et une bourse de 400 euros/mois).
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.
