Spécification par l'exemple

Par Christian Sperandio

- 7 minutes de lecture - 1305 mots

Cet article est pour…

Les équipes de développement dont le travail repose sur des spécifications fonctionnelles.

Le contexte

Nous sommes dans une société avec des équipes métiers et une équipe de développement interne.

Le chef de projet informe le démarrage d’un nouveau projet et communique un document, plutôt un pavé, qui contient les spécifications fonctionnelles. Pour être sûr de répondre aux besoins client, des comités de relecture sont organisés avec les parties métier et développement pour apporter des questions et autres remarques. Après quelques comités de relecture, le document est validé et la phase de réalisation commence.

Une première version est présentée avec les réactions suivantes:

  • le métier se plaint de certains résultats obtenus
    • les développeurs affirment que cela répond aux spécifications fonctionnelles
    • le métier répond que ce n’est pas le cas
    • grognement du développement
    • exaspération du métier
  • le métier demande « pourquoi on ne peut pas faire telle action ? »
    • le développement répond qu’il est explicitement écrit dans les spécifications que cette action ne sera pas autorisée
    • le métier répond que cette action doit être possible sinon le produit ne sert à rien
    • grognement du développement
    • exaspération du métier Avez-vous un air de déjà vu ?

Le problème est…

ce document, souvent indigeste, que nous appelons « spécifications fonctionnelles ».

Souvent ce document doit répondre à un certains formalisme qui a tendance à généraliser les fonctionnalités du produit. Dans certains cas, il est même rédigé par un chef de projet technique qui ne pourra s’empêcher de placer ici et là des réflexions de conception.

Pourtant, il y a eu les comités de relecture. Alors, pourquoi en arrivons-nous à des situations d’incompréhension entre le métier et le développement ? Cela vient du formalisme des spécifications fonctionnelles qui entraine la généralisation et une forme d’abstraction des fonctionnalités. Le métier a réfléchi au produit, il voit les cas concrets et les exemples. Du côté développement, on pense comprendre ce que va faire telle fonctionnalité en lisant une description de celle-ci.

Imaginons que nous travaillons sur la base SIRENE de l’INSEE et que nous ayons la fonctionnalité suivante: « le système retourne les établissements domiciliés dans un code postal donné ». Le développeur va penser que c’est juste une requête sur la table ETABLISSEMENT avec une clause WHERE. Ok, c’est facile. Mais pour le métier, il est évident de ne pas récupérer les auto-entrepreneurs et les sociétés civiles immobilières. Comme la description est évidente pour chacun, il n’y aura pas de question et la dissonance cognitive apparaitra lors de la démo de la fonctionnalité.

En principe, cela ne devrait pas poser de problème: le métier explique le problème et le développement corrige. Mais l’exaspération apparait à cause du document: des heures ont été passées dans sa rédaction, sa relecture et sa correction. Le nombre de corrections dues aux incompréhensions pouvant devenir important, il y a un risque que les spécifications fonctionnelles ne soient pas mises à jour et qu’un décalage entre le code et la documentation s’installe.

Existe-t-il un moyen d’économiser du temps, de l’énergie, d’avoir une spécification au plus près de ce que veut le métier et une documentation au plus près du code ?

La réponse est …

la spécification par l’exemple (Specification By Example ou SBE) qui est un moyen de suivre le Behaviour Driven Development .

Cela consiste à laisser le métier fournir les exemples des fonctionnalités qu’il désire pour un produit. Cela en évitant de passer par l’interprétation impliquée par la rédaction d’un document comme les spécifications fonctionnelles.

L’objectif est d’avoir des spécifications:

  • utilisables comme une documentation toujours à jour (living documentation)
  • testables automatiquement
  • modifiables rapidement
  • lisibles et compréhensibles par le métier et le développement

Comment ?

Par des tests unitaires classiques

Le point le plus important est d’avoir des exemples métiers réels en entrée afin de valider l’implémentation. Cette validation peut parfaitement se faire par l’utilisation de librairies ou framework de tests habituels.

Il y aura néanmoins un impact sur l’écriture de ces tests: le point de départ est le besoin métier, ce qui signifie que le devéloppement est dans une logique TOP - BOTTOM plutôt que BOTTOM - TOP.

Un autre point d’attention est le partage de l’information avec le métier. La base de compréhension sera le code du test, qui n’est pas forcément accessible aux personnes du métier. Pour des règles simples, cette solution est envisageable.
Par contre, pour des règles plus complexes, adopter une solution orienté scénarios est préférable.

Utiliser une framework d’exécution de scénarios

Pour cela, il est nécessaire d’utiliser un langage de spécification et un moteur d’exécution qui est capable de traité ce langage.

Il ne faut pas négliger la courbe d’apprentissage et la complexité induite, aussi bien du côté métier que développement afin d’écrire des scénarios de qualité.

Le langage qui est souvent utilisé pour décrire une spécification est Gherkins .
Ci-dessous un exemple de ce langage:

L’un des exemples les plus bateaux qui existe image alt text

Les valeurs en rouge sont traduites en valeurs de variables qui seront utilisées par le moteur d’exécution. Il est donc possible d’écrire différents exemples avec des valeurs différentes. L’exemple ci-dessus est en anglais mais la plupart des moteurs intègrent plusieurs langues comme le français, espagnole, etc.

Un des moteurs qui sait traiter ce genre de fichier est Cucumber . Ce moteur est multi-langages (Ruby, Java, etc.).

Un tel format offre un langage commun et compréhensible par tous les intervenants. Si des changements sont nécessaires, il “suffit” de modifier la description. J’ai mis des guillements parcequ’il faut garder à l’esprit que le moteur d’exécution des scénarios reste un automate se basant sur une reconnaissance de patterns textuels. Tout ajout ou modification de ces patterns doit être pris en compte dans le développement des tests.

Les dév vont recevoir directement les scénarios du métier
Coupons court à cette croyance: dans l’immense majorité des cas, les scénarios seront rédigés par l’équipe de développement. Même si le formalisme de l’écriture des scénarios semble simple, cela reste un formalisme à acquérir. Le métier peut ne pas avoir le temps, la capacité ou la volonté à cette acquisition. Si cela se fait alors c’est une excellente chose, mais il faut vraiment voir les scénarios avant tout comme un moyen de communication entre les différents intervenants du projet. Qui les rédige n’est pas le point le plus importante.

Il ne faut pas non plus retomber dans le travers où des personnes travaillent sur les scénarios pendant des jours dans leur coin pour ensuite les envoyer en disant que le travail de spécification est terminé. De bons scénarios sont issus d’un travail collaboratif et itératif.

Un autre avantage est la gestion des régressions. En intégrant l’exécution des spécifications après chaque changement dans le code, il est possible de détecter toute modification qui entrainent l’échec d’une spécification.

Quand devons-nous utiliser la SPE ?

Utiliser des exemples réels pour définir les cas de tests doit être la règle. Dans le développenment, nous travaillons souvent avec des abstractions, mais les applications fonctionnent dans le monde réel. Autant utiliser de vrais données pour valider l’implémentation.

Concernant l’utilisation de frameworks comme Cucumber, cela reste à voir. Si les règles métiers sont simples, sont peu dépendantes du contexte alors le surplus de travail liè à l’utilisation de tels frameworks est probablement superflu. Comme toute intégration, il est impératif d’évaluer les avantages vis-à-vis de l’ajout de la complexité.

Ressources

Cela vous semble-t-il intéressant ? Voulez-vous plus d’informations sur l’utilisation de la spécification par l’exemple comme méthode ? Pour cela, je vous conseille les livres suivants:

  • Specification By Example de Gojko Adzic
  • Writing Great Specifications Using Specification by Example and Gherkin de Kamil Nicieja

Ces livres vous apporterons des cas d’utilisation et fourniront toutes les informations nécessaires pour l’intégration de cette méthode.

Bonne lecture !

Note:
Cet article a été publié en 2018 sur mon premier blog .
Je l’ai enrichi suite à de nouvelles expériences.