B.D.D. en toute sérénité

Le concept de qualité d'un logiciel est un (très) vaste sujet. Sujet que je tente d'appréhender depuis quelques années par la biais le plus simple à mon sens : le logiciel fait-il ce qu'on attend de lui ? Question simple en surface car contrôler le comportement d'un logiciel est de plus en plus simple. Reste le problème de savoir exprimer ce qu'on attend du logiciel, et c'est bien le facteur humain qui pose problème ici : comment extraire un concept d'un individu A pour le transmettre à (au moins) un individu B.

Voici comment concilier la simplicité du contrôle qualité et une façon simple d'en spécifier le comportement.

« Dessine mois un bouton »

Non, le Petit Prince n’est pas enrhumé. J'aime beaucoup ce passage illustrant les échanges entre ce petit bonhomme souhaitant un mouton et le narrateur qui fait ce qu'il peut pour répondre à la demande. Cela évoque-t-il aussi chez vous un sentiment de déjà vu ? La phase de spécification où l'on exprime ce que l'on attend du logiciel et après test où l'on retrouve ce genre d'échange. La phase de spécification a selon moi un impact évident sur la qualité du logiciel et beaucoup de technique existent pour faciliter, voir optimiser cette étape.

« d.d.p.? nan, B.D.D. ! »

L’une d’entre elle est la spécification par l’exemple, aussi connue sous l’acronyme anglais B.D.D. pour Behaviour Driven Development. Cette technique est tellement simple que même le petit prince aurait pu s’en servir. Re-visitons, en toute humilité et uniquement pour le besoin de mon propos, le monde créé par Antoine de St Exupéry et imaginons une fin différente. Voici comment le Petit Prince aurait pu exprimer de manière concise ET précise le mouton qu’il souhaitait :

• Étant donné cette feuille de papier et ce crayon,
• Quand tu dessineras un mouton,
• Alors je pourrai voir un animal à quatre pattes, dépourvu de toutes cornes et couvert d’une fourrure claire et frisée.

Une question pour toi public : tu le vois le mouton, n’est-ce pas ?

Merveilleuse technique que celle ci permettant d’aligner les exigences sur les détails attendus du mouton sans pour autant devoir connaitre l’art du dessin ni contraindre la créativité du dessinateur.

« Il dit qu’il voit pas le rapport »

Prenons un exemple tout aussi poétique : le jeu de la vie. Dans ce jeu où l’ordinateur joue seul, une horloge stimule perpétuellement un monde aux dimensions infinies empli de cellules collées les unes aux autres. Chacune d’entre elles obéit à quelques règles bien précises que l’on pourrait reformuler ainsi :

• Étant donné une cellule vivante entourée de plus de 3 cellules vivantes
• Quand le monde sera passé à la prochaine génération
• Alors cette cellule sera alors morte

Et ainsi :

• Étant donné une cellule vivante entourée de moins de 2 cellules vivantes
• Quand le monde sera passé à la prochaine génération
• Alors cette cellule sera alors morte

Et encore ainsi :

• Étant donné une cellule morte entourée de 3 cellules vivantes
• Quand le monde sera passé à la prochaine génération
• Alors cette cellule sera alors vivante

On remarquera dans cet exemple que ni la technologie, ni l’implémentation du système n’entre en jeu. De plus, la multiplication de ces scénarios ajoute à chaque fois un nouveau coup de projecteur, diminuant ainsi la part d'ombre où se tapissent bugs et autres comportements aberrants.

« Bon OK, ce n’est pas le même document Word™ et après ? »

Ai-je mentionné qu’il était possible d’exploiter cette description à des fins de contrôle qualité ? Et de connaître l’état d’avancement des développements ? Et tout ça dans une jolie page Web ?

Vous découvrirez comment en regardant cette vidéo d’une vingtaine de minutes :

TL;DR

Votre temps est précieux ? je comprends, alors voici un résumé :

• JBehave est un framework permettant d'exploiter une spécification écrite en langage naturel, il suffit juste d'un simple éditeur de texte et d'un chouïa de rigueur;
• Serenity est un outil produisant un rapport précisant la part des étapes manquantes aux tests ainsi que le résultat de ceux qui sont implémentés, idéal pour communiquer sur l'état d'avancement de la couverture de test et des développements;
• Ce que ne montre pas la vidéo, c'est qu'en couplant le tout à Selenium par exemple, il devient aisé de tester une application Web.

Conclusion

Cette description comportementale peut servir à n'importe quel moment : pendant la phase de spécification des attentes mais également au moment de la description d'un dysfonctionnement constaté en phase de test par exemple et ouvrant la voie à une nouvelle description du comportement attendu, considéré comme cette fois comme correct.

Cerise sur le gâteau, pas la peine de tout savoir à l’avance, cette technique vieillit très bien et supporte même l’évolution par incrément.

Et avec de bons outils, il est possible de minimiser la duplication de l'information, de l'exploiter sur le plan de l'ingénierie logiciel tout en bénéficiant d'un support de communication sur le contenu du logiciel grâce à de jolis rapports.

Questions

Si vous êtes développeur(e) ou mettez au point une solution

• Quel type de spécifications lisez-vous ?
• Quelle sont les limites / avantages dans la perception de la demande ?

Si vous êtes à l'origine des demandes d'une solution

• Quel type de spécifications écrivez-vous ?
• Quelles sont les limites / avantage dans la description de vos besoins ?