Documentation sur

14
De la story
aux tests d’acceptation
À l’occasion d’un audit sur le processus de développement d’une entreprise, j’avais
constaté que la documentation relative aux spécifications et aux tests était abondante
et, qu’à mon avis, c’était du gaspillage. L’entreprise en question était organisée avec
une séparation entre le service des représentants des utilisateurs (maîtrise d’ouvrage)
et celui des informaticiens (appelé maîtrise d’œuvre) :
• Le premier rédigeait un document de spécification fonctionnelle du besoin.
• Le second répondait par un document de spécification du logiciel pour montrer
ce qu’il avait compris des demandes des utilisateurs.
• Il développait le logiciel et passait des tests unitaires, des tests d’intégration mais
aussi des tests fonctionnels écrits en interne.
• L’équipe de test de la maîtrise d’ouvrage rédigeait un cahier de recette, pas fourni
au préalable, qu’elle passait sur le logiciel reçu des informaticiens.
Cela faisait quatre documents, tous décrivant le comportement du produit ! C’est
pour éviter ce genre de gaspillage que les méthodes agiles préconisent d’avoir un seul
référentiel pour les spécifications et les tests.
Un article publié dans le très sérieux magazine IEEE Software1 fait l’hypothèse de
cette équivalence entre les tests et les exigences. La référence au ruban de Möbius
illustre comment les deux (exigences et tests) se confondent lorsque le formalisme
augmente.
1. L’article Tests and Requirements, Requirements and Tests : A Möbius strip est signé de Grigori Melnik
et de Robert C. Martin, le célèbre Uncle Bob.
182
Chapitre 14. De la story aux tests d’acceptation
C’est l’objectif de ce chapitre de montrer comment les stories, accompagnées de
leurs tests d’acceptation, constituent une spécification par l’exemple.
Le test n’est pas une phase
Tester c’est un processus qui consiste à collecter des informations en faisant des
observations et en les comparant aux attentes. Avec l’approche itérative de Scrum, le
test n’est plus une phase qui se déroule après le développement. Il est intégré dans
chaque sprint. Dès le premier sprint, une équipe commence à tester des stories.
Cette façon de procéder permet de réduire le délai entre le moment où une erreur
est introduite dans le logiciel et celui où elle est corrigée. On sait depuis longtemps
que plus ce délai s’allonge plus le coût de la correction est élevé.
14.1 TEST D’ACCEPTATION
Quelle que soit la méthode de développement utilisée, il existe des tests de nature
différente. Les méthodes agiles apportent une nouveauté dans la façon de percevoir
certains types de tests. En effet, la vue classique du test est la détection d’erreurs a
posteriori, après le travail de développement : le testeur, en cherchant des erreurs, vise
à critiquer. Or, le test agile a un objectif différent, celui de guider le développeur dans
son travail.
Brian Marick met en évidence cette nouvelle vision des tests dans la matrice à
quatre quadrants1 (figure 14.1).
Pilotage
par les tests
unitaires (TDD)
Autres tests
Boîte blanche
Pilotage
par les tests
d acceptation (ATDD)
Autres tests
Boîte noire
Critique
du développement
Guide
pour le développement
Orientation développeur
Orientation client
Figure 14.1 — Quadrants des tests
Cette idée de guide pour le développement transparaît dans le pilotage par les tests
(TDD pour Test Driven Development), centré sur les tests unitaires2 . C’est aussi le but
1. http://www.exampler.com/old-blog/2003/08/21/
2. Le TDD est abordé dans le chapitre 15 Scrum et l’ingénierie du logiciel
183
14.2 Étapes
pour les tests d’acceptation qui sont des tests orientés client (ATDD, Acceptance Test
Driven Development).
Le test d’acceptation est le processus qui permet d’accepter une story à la fin d’un
sprint. Il consiste en plusieurs étapes, appliquées à une story :
• Décrire le comportement attendu avec les conditions de satisfaction.
• Transformer ces conditions en cas de test, appelés storytests.
• Écrire le code applicatif qui répond au comportement attendu
• Passer les storytests sur le code applicatif. En cas d’échec, corriger les tests ou le
code.
Ce processus est appelé pilotage par les tests d’acceptation.
Story
Storytest
Figure 14.2 — Une story possède des storytests
Une user story devrait posséder au moins deux storytests associées : un cas de succès
et un cas d’échec. Il peut y avoir d’autres cas de tests pour une story, mais un nombre
trop important (disons au-delà de huit) est le signe d’une trop grande complexité de
la story, qu’il conviendrait de décomposer.
Pour les stories techniques, la notion de test n’est pas pertinente, on en restera
au niveau des conditions de satisfaction. De même pour une user story, toutes les
conditions de satisfaction ne deviennent pas des tests : c’est le cas de celles qui portent
sur d’autres artefacts que le produit, par exemple sur de la documentation requise.
14.2 ÉTAPES
Définir
les conditions
de satisfaction
Écrire
les storytests
Développer
la story
Passer
les storytests
Figure 14.3 — Les étapes du processus
14.2.1 Définir les conditions de satisfaction
Le principe, pour toutes les méthodes agiles, est qu’une story soit réalisée en une
itération. Mais comment savoir si elle est vraiment finie à la fin de l’itération ?
C’est la responsabilité du Product Owner d’accepter (ou non) une story. Pour cela,
le moins qu’il puisse faire est de définir ses conditions de satisfaction. Si toutes les
184
Chapitre 14. De la story aux tests d’acceptation
conditions sont satisfaites, la story est acceptée, sinon elle n’est pas considérée comme
finie.
Exemple avec la story « Inscription à une conférence ». On peut identifier trois
comportements :
• Inscription acceptée – C’est le cas de succès, l’inscription d’une personne à une
conférence est confirmée.
• Inscription différée – L’inscription n’est pas confirmée faute de place et placée
en liste d’attente.
• Inscription refusée – L’inscription est refusée, la liste d’attente ayant atteint sa
limite.
Pour une user story, une condition de satisfaction peut être formalisée par un test.
14.2.2 Écrire les storytests
Formalisme utilisé pour les storytests
Les différents tests associés à une story correspondent à des comportements différents
du logiciel. Les comportements diffèrent parce que, en fonction de l’état du logiciel au
moment où la story est exécutée, les résultats obtenus seront différents. La technique
du BDD (Behaviour Driven Development1 ) permet de décrire ces comportements.
Chaque test est formalisé avec trois rubriques :
• l’état du logiciel avant l’exécution du test (on parle aussi de précondition ou de
contexte du test) ;
• l’événement qui déclenche l’exécution ;
• l’état du logiciel après l’exécution (on parle aussi de postcondition ou de résultat
attendu).
État avant l exécution
(étant donné)
Événement (quand)
État après l exécution (alors)
Figure 14.4 — Un test BDD
1. http://dannorth.net/introducing-bdd
185
14.2 Étapes
Le formalisme textuel du BDD est le suivant :
Étant donné le contexte et la suite du contexte
Quand l’événement
Alors résultat et autre résultat
Cette façon de faire est particulièrement adaptée à des applications interactives.
Elle pousse à avoir des tests courts, puisqu’on y décrit la réponse à un seul événement.
Exemple avec la story « Inscription à une conférence »
Chaque condition de satisfaction est transformée en test.
Exemple pour inscription acceptée
Étant donné l’utilisateur Benji connecté et la conférence AgileToulouse
avec le nombre d’inscrits à 134 et la salle A4 d’une capacité de 200
associée à AgileToulouse.
Quand Benji s’inscrit à AgileToulouse
Alors l’inscription de Benji est acceptée et le message Vous êtes bien
inscrit à AgileToulouse est envoyé à Benji et le nombre des inscrits passe
à 135.
Exemple pour inscription différée
Étant donné l’utilisateur Pred connecté et la conférence AgileToulouse avec
le nombre d’inscrits à 200 et la salle A4 d’une capacité de 200 associée à
AgileToulouse et 3 personnes dans la liste d’attente.
Quand Pred s’inscrit à AgileToulouse
Alors l’inscription de Pred est refusée et le message Vous êtes en liste
d’attente est envoyé à Pred et le nombre des inscrits reste à 200 et le
nombre de personnes en liste d’attente passe à 4.
Exemple pour inscription refusée
Étant donné l’utilisateur Chipeau connecté et la conférence AgileToulouse
avec le nombre d’inscrits à 200 et la salle A4 d’une capacité de 200
associée à AgileToulouse et 20 personnes dans la liste d’attente.
Quand Chipeau s’inscrit à AgileToulouse
Alors l’inscription de Chipeau est refusée et le message Il n’y a plus de
places disponibles est envoyé à Chipeau et le nombre des inscrits reste à
200 et le nombre de personnes en liste d’attente reste à 20.
Où stocker les tests ?
Chaque test étant associé à une story, il est considéré comme un attribut de la story et
placé avec elle dans le backlog de produit (si l’outil employé le permet ; sinon les tests
peuvent être mis dans un document annexe mais en gardant la référence aux stories).
186
Chapitre 14. De la story aux tests d’acceptation
Quand écrire les tests ?
Si la story est réalisée dans l’itération n, cela implique que les étapes du processus
de test d’acceptation s’y déroulent (pour quelques stories, il faut même faire l’étape
d’écriture des tests dans l’itération n – 1).
Une recommandation est, au moins pour une story du sprint, que ses tests soient prêts
avant le début du sprint et que tous les tests soient prêts à la moitié du sprint.
Les étapes ne sont pas nécessairement séquentielles, l’ajout de nouveaux tests peut
se faire en parallèle avec le développement de la story.
Qui écrit les tests?
Scrum met l’accent sur l’équipe sans spécialiser les rôles. Il n’y a pas de rôle de testeur,
mais cela ne veut pas dire que l’équipe ne teste pas ! Il existe parfois l’idée que c’est le
client qui teste, le client étant représenté par le Product Owner, ce qui peut conduire
les développeurs à déléguer au Product Owner tout l’effort de test.
Ce n’est pas une bonne idée : pour des raisons de quantité de travail et de
compétences, le Product Owner n’est généralement pas en situation pour s’occuper
seul du test d’acceptation et surtout cela doit être un travail collectif.
En fait, peu importe qui rédige les tests, ce qui compte c’est que cela soit fait au
bon moment.
14.2.3 Développer la story
Le développement de la story est mené rapidement pendant le sprint ; il dure, en
moyenne, trois jours, à plusieurs personnes.
Le pilotage par les tests signifie que l’équipe part des tests d’acceptation pour
concevoir et coder la story. Pendant le développement, il est fréquent que des storytests
soient complétés, voire que de nouveaux soient ajoutés.
14.2.4 Passer les storytests
Pour vérifier que la story est bien finie, il faut exécuter ses tests sur la dernière version
du logiciel, le build courant. Si des tests ne passent pas, la correction est faite aussitôt,
l’objectif étant que tous passent avant la fin du sprint.
À chaque nouveau build, pour éviter les régressions, il conviendrait de repasser
tous les tests. C’est une raison pour laquelle il est vite nécessaire de s’intéresser à leur
automatisation.
Intérêt de l’automatisation
À la première itération, on passe T1 tests. À la deuxième, on passe les T2 nouveaux
tests identifiés et on repasse les T1 pour détecter les régressions éventuelles. Cela
donne :
187
14.2 Étapes
Itération
Itération
Itération
Itération
1
2
3
n
:
:
:
:
T1
T2 + T1
T3 + T2 + T1
Tn + .... + T3 + T2 + T1
Avec l’hypothèse d’un nombre moyen Ti des tests par itération, cela donne pour le
nombre de tests à passer :
Total = Ti *n*(n+1)/2
Pour dix itérations avec chacune dix nouveaux tests, le total est de :
Ti=10, n=10, Total = 550
Avec 50 tests par itérations, il devient :
Ti=50, n=10, Total = 2750
On imagine que si les tests ne sont pas automatisés, ils ne seront pas tous passés
manuellement à chaque sprint et que des régressions peuvent ne pas être détectées.
Mesures et indicateurs de suivi de test
Il n’est pas nécessaire de produire une documentation de rapport des tests comme on
en fait dans le développement traditionnel. Il peut être intéressant, lorsque la pratique
est mise en place, de faire quelques mesures. Les mesures sur le nombre de stories tests
existants et sur leur exécution sont importantes pour évaluer la qualité du test. La
collecte1 se fait à chaque build et à chaque fin de sprint.
Figure 14.5 — Évolution des tests à chaque sprint – Dans cet exemple, on voit que le nombre
de tests passés avec succès a diminué entre le sprint 3 et le sprint 4, ce qui est le signe d’un
problème. L’équipe doit analyser ce qui a causé cette régression et en tirer les conséquences.
Cet indicateur met également en évidence qu’il reste des tests en échec à la fin d’un sprint.
1. Voir le chapitre 15 Estimations, mesures et indicateurs.
188
Chapitre 14. De la story aux tests d’acceptation
14.3 GUIDES POUR LE TEST D’ACCEPTATION
À essayer
Se servir des tests pour communiquer
Connecter les tests
Planifier le travail de test
À éviter
Tester une story dans le sprint suivant son développement
Stocker les bugs
14.3.1 Se servir des tests pour communiquer
L’ensemble des stories avec leurs tests remplacent une spécification fonctionnelle
détaillée, avec un bénéfice essentiel : la communication est facilitée entre le métier et
le développement.
Les membres de l’équipe sont demandeurs de ces tests. Ils s’en servent dans les
discussions avec le Product Owner et les testeurs. Ils les complètent si c’est nécessaire.
Le référentiel des tests est complété progressivement et toujours à jour.
Cela montre que cette façon de faire – dans façon de faire j’inclus bien plus que du
test ; en fait je pense que le mot test est trompeur : au lieu de test d’acceptation,
spécification par l’exemple serait probablement plus approprié – est un moyen
d’obtenir une meilleure compréhension entre le métier et le développement, et procure
un apport absolument fondamental.
14.3.2 Tester une story dans le sprint où elle est développée
Un des constats fait en suivant des équipes Scrum qui débutent est que de nombreuses
stories ne sont pas finies en un sprint. Quelques-unes durent même plusieurs sprints !
Ce problème est souvent dû à l’accostage développeurs-testeurs. Si un testeur
reçoit le logiciel à tester en toute fin de sprint, au mieux il découvre des erreurs qui
ne pourront pas être corrigées avant la fin du sprint, au pire il diffère ses tests au sprint
suivant.
Ne pas développer, tester et corriger une story dans le même sprint est un
dysfonctionnement sérieux auquel il faut s’attaquer. Pourquoi est-ce un problème ?
• Cela diminue la productivité des développeurs qui doivent se replonger dans
le code qui implémente une story qu’ils ont développée dans une itération
précédente.
• Ce n’est pas satisfaisant pour l’équipe. Elle s’est engagée au début de l’itération
à finir une story et le résultat montre que ce n’est pas fini.
• Cela rend la planification plus difficile. Une user story pas finie est comptée
à zéro point pour la vélocité alors que du travail a été effectué dessus. Cette
décorrélation entre résultat et travail tend à produire un burndown chart de
release en dents de scie, ce qui peut être perturbant.
14.3 Guides pour le test d’acceptation
189
Le testeur doit être impliqué dans la planification du sprint, s’engager avec le reste
de l’équipe et être très réactif. L’équipe doit aussi être capable de refuser d’inclure une
story dans un sprint si elle estime qu’elle n’est pas suffisamment définie.
14.3.3 Ne pas stocker les bugs
Un story développée dans un sprint est testée dans ce sprint. Si un test ne passe pas
avec succès, l’équipe doit effectuer la correction au plus vite et au plus tard avant la
fin du sprint.
Si à la fin du sprint tous les tests ne passent pas avec succès, la story n’est pas
montrée lors de la revue et n’est pas considérée comme finie. On ne stocke pas les
bugs, on stocke les tests.
14.3.4 Connecter les tests d’acceptation
La technique des « user stories » est très efficace couplée à un développement par
itérations. Les stories alimentent le backlog de produit et sont développées pendant
l’itération. La tendance est à avoir des stories très petites, ce qui présente des avantages
en termes de gestion et de suivi. Mais cela a l’inconvénient de rendre les choses plus
difficiles à comprendre. Une story est à replacer dans un contexte plus large pour que
l’on identifie son usage.
En fait une story ne suffit pas pour raconter une histoire qui parle aux utilisateurs.
Par exemple lors de la revue, à laquelle participent de nombreuses personnes, il
convient de préparer une démonstration qui enchaîne des user stories. C’est ce qu’on
appelle un scénario.
Sur un projet de gestion documentaire auquel j’ai participé, deux scénarios ont été
présentés lors de la revue de sprint. Nous avions identifié et sélectionné pour ce sprint
des stories comme :
• créer un document,
• télécharger un document existant,
• commenter un document,
• désigner les approbateurs,
• déléguer l’approbation,
• approuver un document.
La démonstration a montré d’abord le cas d’un nouveau document créé et approuvé
(scénario 1), puis celui d’un document téléchargé puis délégué dans un mécanisme
d’approbation en série (scénario 2).
Souvent les scénarios font référence à des utilisateurs fictifs, appelés user1 ou toto. Il
est préférable de choisir de vrais utilisateurs. De la même façon, plutôt que de prendre
des documents appelés doc1, il vaut mieux s’appuyer sur un exemple réel qui rend les
choses plus concrètes et facilite leur compréhension.
190
Chapitre 14. De la story aux tests d’acceptation
Les scénarios sont utiles pour la démonstration en fin de sprint, mais c’est mieux de
les élaborer bien avant. En début de sprint, ils donneront à toute l’équipe le contexte
pour le travail de développement.
14.3.5 Planifier le travail de test
Pour chaque story, on peut identifier deux tâches pour mener à bien le test d’acceptation :
• La spécification des tests de cette story, qu’on peut séparer en identification du
test et formalisation du test.
• Le passage de ces tests.
C’est du travail qui prend du temps, c’est pourquoi les tâches de test doivent figurer
dans le plan du sprint.
Résumé
Le test n’est pas une activité réservée à la fin des développements. Avec les méthodes
agiles, les tests d’acceptation sont passés à chaque sprint. Le pilotage par les tests
d’acceptation pousse même à définir le test d’une story avant son développement,
pour qu’il serve de spécification par l’exemple à l’équipe.