La taverne du testeur

11 : Concevoir rapidement les scénarios de tests d’une US INVEST avec des “tamis successifs”

Rappelons que le travail des 3 amigos (Développeur, testeur et Product Owner) va consister en ATDD à :

  • Valider les RG qui spécifient la tâche (celle-ci représente en effet l’US initiale, dont il faut assurer la non-régression, et ses corrections de détail dont il faut garantir la bonne implémentation).
  • Choisir ensuite, en fonction du risque encouru par la tâche (l’US si aucune erreur de spécification n’intervient) et de sa valeur, la couverture de test que l’on désire. En principe la capacité à faire n’a pas à être un obstacle, sinon la qualité pourra se révéler moindre que celle attendue. 

Ce principe nous le reprendrons au niveau des autres éléments du produit et de la prise en compte des tickets agiles de plus grande granularité.  

Ainsi l’algorithme des tamis successifs, que nous préconisons (en réalité ayant un énoncé pour les US et un autre pour les autres artefacts métiers), vise à fournir des tests progressivement, jusqu’au niveau de qualité attendu, et de manière simple.

 Algorithme protégé par la marque “Modern Product Agility”.

Énoncé de l’algorithme pour une US

On part de l’hypothèse que les exigences fonctionnelles de la solution sont rédigées en BML, soit sous la forme textuelle, soit sous une forme tabulaire.

Dans ce cas, on essaie, en cochant les différents pas de test par un n° (du n°1 au n° x qui sort de l’US), d’aboutir aux buts suivants :

  1. Parcourir l’US via le chemin nominal (chemin le plus courant qui traverse l’US)
  2. Parcourir l’US pour couvrir au moins une fois chaque objectif d’US (par objectif d’US il faut entendre les ”sorties boîte noire” de l’US, qui peuvent être reprises pour les tests d’intégration)
  3. Parcourir l’US pour couvrir au moins une fois chaque étape 
  4. Parcourir l’US pour couvrir au moins une fois chaque RG
  5. Parcourir l’US pour couvrir au moins une fois chaque alternative dans une condition (avec un/des OU)

L’algorithme permet des taux de couverture progressifs 

Cet algorithme est progressif car les buts sont de plus en plus difficiles à atteindre

Pour autant, il arrive parfois que plusieurs buts soient atteints avec un même scénario de test.

Chaque scénario de test explicite tous les résultats intermédiaires.

Chaque scénario de test donne lieu à un critère d’acceptation qui se formule sous la forme :

Etant donné que <pré-requis du scénario> 

Quand <liste des conditions satisfaites>

Alors <objectif de l’US atteint>

Le critère d’acceptation perd ainsi l’annotation des résultats intermédiaires, sauf à les fournir en commentaires (ce qui est peu rigoureux, inacceptable, peu exploitable).

Exemple de critères d’acceptation obtenus par l’algorithme des tamis successifs pour l’US INVEST

Prenons l’exemple d’une authentification simple. 

Le critère d’acceptation 1 représente le chemin nominal.

Etant donné que je suis client ou prospect identifié,

QUAND  l’identifiant est saisi correctement à la première tentative

ET           le mot de passe est saisi correctement à la première tentative

ALORS   la connexion au site est réussie.

Le tableau est auto-suffisant et précis (tous les comportements intéressants pour le développeur et le testeur y figurent). Il est inutile en fait d’écrire le critère d’acceptation sous forme GHERKIN puisqu’il se déduit du texte des RG traversées. C’est donc très rapide (agile !). Il suffit de se concentrer sur les spécifications (RG) et d’appliquer l’algorithme qui s’avère être efficace et aligné sur les objectifs du testeur.

Ce critère n°1 atteint ainsi l’objectif de connexion : O1.

Donc la prochaine étape de l’algorithme est d’arriver à tester O2, et tant qu’à faire, en ajoutant des nouvelles RG testées !

On s’aperçoit qu’après ce 2ème critère d’acceptation :

  • On a aussi traversé toutes les étapes (1 et 2) au moins une fois !
  • Mais RG2-2 et RG2-3 n’ont jamais été testées (en fait nous sommes à 4/6 de RG testées, soit 66%).

D’où le critère d’acceptation n°3 pour compléter la couverture des RG à 100%.

Dans cet exemple, il n’y a pas d’alternatives dans les conditions, donc l’algorithme s’arrête.

La méthode est ainsi très rapide, systématique. Les scénarios de test sont mis en évidence et le principe de leur génération repose sur une logique parfaitement compréhensible et justifiée. Reste donc à parler de leur implémentation sous la forme de “tests”, c’est-à-dire en utilisant des valeurs pour les données manipulées. 

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

culture générale

Ce que nous apprend les mythes sur les tests: Thésée et le Minotaure

L’histoire de Thésée et du Minotaure La cité d’Athènes était contrainte, tous les 9 ans de « livrer » 7 jeunes hommes et 7 jeunes femmes aux crêtois pour les donner en sacrifice au Minotaure suite à une défaite militaire. Un jour, Thésée, prince d’Athènes et fils du roi Egée convainc son

Lire la suite »
Agilité

Le testeur Agile

Le testeur Agile, un vaste sujet Ces dernières années les méthodes agiles impactent fortement le métier de testeur. Comme toute transformation il est impossible de savoir où ces changements vont nous mener, il est par contre important d’essayer d’anticiper un maximum ces modifications de notre travail afin de s’y adapter.

Lire la suite »
Avenir

Enquête CFTL: les axes d’améliorations pour le test

Les résultats de l’enquête 2023 de CFTL sont disponibles. Cette enquête permet de faire un état des lieux régulier du test depuis plus de 10 ans. Cela permet de ce faire une idée des évolutions du test en plus de savoir, à un instant t, quelles sont les problématiques, les

Lire la suite »