Tests d’acceptation : dérives à éviter

À quoi ressemble une démarche d’automatisation des tests d’acceptation ? D’un point de vue humain, d’un point de vue process ? Quelles sont les étapes habituelles dans le quotidien d’une équipe ?

Voici un process canonique pour un nouveau développement :

Réunion des 3 Amigos ou similaire pour définir les exemples qui illustrent l’évolution
Rédaction des tests au propre sous forme de spécifications exécutables par un des 3 Amigos
Revue croisée par les autres Amigos
Implantation par les développeurs en ATDD / Test First

Étapes typique de rédaction des tests d’acceptation automatisés

Dérives courantes

Selon le contexte de l’équipe, on peut constater différentes variations par rapport à cette approche canonique. Il s’agit généralement de dérives dangereuses.

Pas d’étape de définition des exemples, on part directement sur la rédaction des tests

L’étape de définition des exemples est d’autant plus importante que l’équipe est dans une démarche de co-conception voire de conception émergente — contexte nécessaire pour tirer tout l’intérêt de l’approche BDD (Behavior-Driven Development).

Si au contraire l’équipe est dans un contexte où on lui soumet une solution à implanter, plutôt qu’un problème à résoudre, cette étape perd une partie de son intérêt. L’étape reste importante mais ne sert plus qu’à s’assurer d’une bonne compréhension mutuelle de la solution à implanter.

Certaines équipes ne ressentent pas le besoin de cette étape pour arriver à une telle compréhension mutuelle. Attention, il est rare que se passer complètement de cette étape soit vraiment une bonne idée. Construire une compréhension mutuelle reste une exercice extrêmement difficile, comme l’explique si bien John Cutler (lien à la fin de l’article).

Il est cependant possible que la forme de cette étape change d’une équipe à une autre. Par exemple, en flux continu type Kanban, cette étape pourrait être complètement intégrée dans le travail de développement plutôt que dans une étape dédiée. Cette étape n’apparaitrait donc pas explicitement, mais existerait tout de même : avant de rédiger les tests, une phase préparatoire de définition du besoin a lieue.

On peut aussi imaginer que cette étape, plutôt que de prendre la forme d’un atelier ou d’un échange verbal entre collaborateurs, prenne la forme de fils de discussions dans un outil de messagerie ou de gestion de ticket.C’est alors une forme de travail très différente, qui favorise les échanges asynchrones, mais dont certaines entreprises sont friantes comme par exemple Basecamp (lien à la fin de l’article).

Néanmoins, cette étape de construction d’une compréhension mutuelle a bien lieue.

Rédaction des tests en séance

Il peut être tentant de rédiger directement les tests en séance lors des échanges de définition des exemples.

Je met directement en garde contre cette approche, qui risque d’être inefficace.

D’un côté, la définition des exemples est une activité qui a les caractéristiques suivantes :

Collaborer tous ensemble
Rebondir sur les idées des autres et les raffiner mutuellement
Faire émerger une solution
Remettre en question les besoins exprimés et la solution
Essayer d’être complet dans la réflexion sans être exhaustif dans la formulation
Utiliser toutes sortes de formalismes pour énoncer les exemples, tels que des listes à puce, des flèches, des dessins, des tableaux

On pourrait donc qualifier la définition des exemples de moment très créatif.

À l’inverse, la rédaction des tests recouvre beaucoup d’autres d’activités :

Reformuler les exemples sous la forme de tests
… Qui satisferont donc les contraintes de l’outil (texte qui respecte une certaine syntaxe, nomenclature des fichiers…)
… Et qui seront de véritables exemples, c’est à dire où les valeurs sont bien figées, un élément nécessaire à l’automatisation
Réutiliser les éléments de test déjà définis dans le cadre de précédents tests
S’assurer de l’homogénéité de la rédaction avec l’ensemble de la base de test
… Que cela soit dans le choix des termes métiers utilisés
… Ou dans les modèles de rédaction utilisés
Suivre les bonnes pratiques de test
… Et si nécessaire décomposer les exemples en plusieurs tests pour les rendre à la fois plus rapides, plus faciles à maintenir et plus lisibles
Faire la part des choses entre complétude de la couverture par les tests et lisibilité de l’ensemble
Ajouter ces tests dans le gestionnaire de version (GIT)

Si l’étape de définition des exemples est un moment hautement collaboratif qui sert à faire émerger l’intelligence collective, l’étape de rédaction des tests s’apparente plus à du développement, où on transforme des concepts abstraits en du texte concret qui respecte un certain nombre de contraintes.

Aussi, à moins d’être adepte du mob programming (lien à la fin de l’article) cette activité ne se fera pas avec toute l’équipe. Et même dans ce cas, il est certainement plus constructif de traiter la rédaction des tests comme un moment différent de la définition des exemples puisque les deux activités requièrent un état d’esprit assez différent.

Pas de revue croisée des tests

Lors de la rédaction des tests, l’expertise des 3 Amigos doit être mise à profit :

Formulation en termes métier, seul vocabulaire pérenne
Tests compatibles avec les contraintes techniques, permettant de les mettre en place et de les exécuter rapidement
Respect des bonnes pratiques de test

La revue croisée est un moment important parce qu’il permet de s’assurer de tous ces points, indépendamment de quel Amigo a fait le travail de rédaction des tests.

Une dérive classique, en l’absence de cette revue croisée, est donc d’oublier de prendre en compte tous ces aspects, par exemple :

Cas de tests techniques manipulant des éléments techniques, qui se retrouvent à la fois peu lisibles, fragiles et difficiles à maintenir
Cas de tests négligeant la faisabilité technique des tests, résultant en des développeurs qui trichent dans l’implantation du test plutôt que de réellement brancher les cas de test sur le code de production pour le tester

La revue croisée reste le dernier moment où l’on s’assure des échanges et de la collaboration entre les 3 Amigos. Sans la revue croisée, il y a un réel risque de formuler des tests qui ne seront pas pérenne, ou qui feront perdre du temps par la suite du développement.

Le code de production est écrit avant d’implanter le test

Cette dérive remet en question l’ensemble de l’approche : à quoi bon écrire un test d’acceptation une fois que le code a été écrit ?

Un test d’acceptation sert à guider le développement. Une fois que le code a été écrit, il n’y a plus besoin de ce guide.
L’implantation d’un test est difficile dès lors que le code n’a pas été prévu pour le permettre. En écrivant le test après, on se retrouve généralement à complexifier le code de test pour réussir à le faire fonctionner.

Pour aller plus loin

Que pensez-vous de cet article?

J’apprécierais vraiment si vous pouviez me laisser un commentaire pour me dire ce que vous appréciez ou ce qui pourrait être amélioré dans cet article.

Et si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !

À bientôt 😊

Tests d’acceptation : dérives à éviter