Visual ATDD – Model-Based Testing en Agile

Vous connaissez probablement ce scénario : au début d’une nouvelle année (scolaire), nous prenons des résolutions. Une résolution qui a gagné en popularité, surtout dans l’ère post-Covid, est de « faire plus d’exercice ». Cependant, au fur et à mesure que la vie quotidienne prend le dessus, nous nous occupons de diverses tâches, laissant peu de temps pour nos résolutions. Une année passe et nous réalisons que nous aurions dû nous concentrer davantage sur notre activité physique. La résolution n’a pas été oubliée ; elle n’a simplement pas été mise en œuvre de manière cohérente.

Il en va de même pour les bonnes résolutions en Agile. Dans notre contexte spécifique, la résolution s’appelle « Shift Left ». Nous reconnaissons l’importance de traiter les tests le plus tôt possible. Et pourquoi donc ? Eh bien, premièrement, cela garantit que les tests ne manqueront pas à la fin. Deuxièmement, lorsque la conception des tests commence, elle révèle souvent des exigences incohérentes, peu claires ou manquantes parce que quelqu’un examine systématiquement et de manière critique ces exigences. Cela permet de clarifier les problèmes ouverts pour l’ensemble de l’équipe de projet, augmentant ainsi la probabilité de prévenir l’apparition de défauts.

La forme la plus répandue du « Shift-left testing » est le développement piloté par les tests, une approche appelée ATDD (Acceptance Test-Driven Development. Son représentant le plus connu est le BDD (Behavior-Driven Development). Au lieu d’affiner les histoires d’utilisateurs avec des tests d’acceptation textuels, nous écrivons immédiatement les scénarios de tests d’acceptation. Ceux-ci sont généralement écrits dans la syntaxe semi-formelle Gherkin (GIVEN-WHEN-THEN), car de cette manière, ils peuvent être lus et automatisés.

Les scénarios Gherkin conviennent bien aux user stories, mais moins aux fonctionnalités ou aux épopées entières. C’est là que le model-based testing intervient. Son idée principale est de représenter graphiquement le flux de test, d’ajouter les informations nécessaires concernant le test de chaque action, puis d’utiliser un générateur de cas de test pour créer les cas de test requis pour une couverture particulière. Le générateur de cas de test collecte toutes les informations stockées sur le chemin à travers le flux de travail et compile – en fonction de l’outil – des cas de test abstraits ou concrets, des spécifications de procédure de test et/ou des scripts de test pour l’automatisation.

Le paragraphe précédent contient une information très importante que vous ne devriez pas négliger. Les séquences de test sont modélisées, pas le système ! Dans le passé, le MBT était souvent compris comme la réutilisation de modèles existants de la phase de conception du produit. Cependant, comme son nom l’indique, Visual ATDD place clairement le test au début du développement. Comme pour le BDD, le système est spécifié par les flux de travail, les informations stockées dans le modèle et par les scénarios de test générés à partir de celui-ci. ATDD est également appelé « Spécification par l’exemple ». (Les autres approches MBT existent toujours. Elles sont également « Visuelles », mais ne sont pas ATDD.)

Pourquoi est-ce important ? Parce que nous souffrons tous d’un manque de temps. Même si cela ne devrait pas être le cas, il y a toujours les nombreuses petites choses mentionnées au début… Que ce soit pour nous protéger ou par notre paresse intérieure, nous résistons à toute tâche qui semble être une étape supplémentaire. Pourquoi devrais-je créer un modèle si je n’ai besoin que de cas de test à la fin ? Pourquoi gaspiller une pensée sur une conception de test structurée si nous finissons par automatiser tout ?

Comme avec BDD, dans Visual ATDD, nous décrivons le système en utilisant les exemples fournis par les spécifications de test. Ainsi, chaque membre de l’équipe sait ce qui est attendu ou ce qui sera considéré comme acceptable à la fin. Contrairement au cas de la réutilisation, dans Visual ATDD, il n’y a qu’un seul modèle, qui est le modèle de test. Cela évite les redondances et la difficulté de maintenir deux modèles à jour en parallèle.

Étant donné que les tests sont générés à partir du modèle, il y a une forte incitation à maintenir le modèle à jour. Cependant, la tentation de simplement maintenir manuellement les tests une fois qu’ils ont été générés reste toujours présente. C’est là que le support d’outils est essentiel. L’outil de conception de test visuel Yest® de Smartesting est un véritable IDE pour les testeurs. De nombreuses fonctions telles que l’auto-complétion, la propagation des modifications, l’analyse d’impact, les fonctions de recherche avancées et bien d’autres encore facilitent le travail fastidieux de maintenance des cas de test pour les testeurs.

Mais revenons à Visual ATDD. Le modèle (toujours à jour grâce à Yest®) représente une documentation vivante du produit. Les nouveaux arrivants sur le projet en bénéficient autant que les anciens qui veulent rechercher quelque chose datant de trois mois auparavant.

L’idée du développement piloté par les tests était que de nombreux problèmes sont remarqués avant qu’ils ne soient « gravés » dans le code source. Mais cela ne fonctionne que si nous commençons vraiment tôt avec notre conception de test. Visual ATDD permet une approche descendante, en commençant par le flux général des actions. Les détails sont ajoutés dès qu’ils sont disponibles. Si nécessaire, les flux de travail sont étendus sprint par sprint par les 3 Amigos. Le modèle croît ainsi de manière itérative et incrémentale dans une véritable façon de travailler agile.

D’un point de vue technique, Visual ATDD ne diffère pas du MBT « traditionnel ». Ce sont les aspects organisationnels qui font la différence. Pour travailler de manière pilotée par les tests, le test doit vraiment être placé au début. Cela signifie également que, si nécessaire, les prestataires de services sont impliqués dès le début. Les avantages sont évidents. : la qualité augmente intrinsèquement grâce à une communication nettement améliorée rendue possible par une représentation graphique claire. Grâce à l’outil Yest®, il est plus simple de mettre à jour les modèles que de revoir les tests existants, ce qui permet de boucler la boucle de manière fluide et efficace !