L’expression du besoin en agile, centrée sur les User Story et leurs critères d’acceptation, permet de définir ce qui doit être implémenté et testé dans l’itération (ou la suivante). Mais les User stories ne permettent pas de connaître le comportement du produit car, une fois implémentées, elles sont oubliées et peuvent être invalidées par de nouvelles user stories.
La mise en pratique croissante de l’ATDD – Acceptance Test Driven Development – et du BDD – Behavior Driven Development, de mieux en mieux supportée par les outils de test, offre une double réponse :
- Les scénarios de tests d’acceptation sont exprimés de façon intelligible, tant pour l’équipe agile que pour les experts Métier, et ils participent de la clarification du besoin ;
- Ces scénarios ATDD et BDD sont automatisés et maintenus comme tests de non-régression, constituant un matériel à jour sur ce que fait le produit
L’idée est bien de faire d’une « pierre deux coups », en réalisant deux choses à la fois avec une seule action : écrire les tests d’acceptation le plus tôt possible et constituer une documentation vivante du produit.
Ces pratiques sont de mieux en mieux prises en charge par les outils de tests, tant au sein des plateformes de test en agile, qu’au niveau des outils de conception et d’automatisation des tests. Deux approches principales sont proposées : utiliser une description textuelle ou une description visuelle des scénarios. Prenons l’exemple d’un système de gestion du remboursement des frais de déplacement et la User Story suivante : « En tant que membre du département RH, je veux pouvoir vérifier la note de frais d’un employé et lui indiquer si besoin les éléments manquants ou erronés, afin de m’assurer que la demande est valide et qu’elle pourra être remboursée par le comptable ». Voyons comment les scénarios de tests d’acceptation ATDD / BDD peuvent être définis de façon textuelle, ou de façon visuelle pour cette User Story.
Scénarios sous une forme textuelle – Le langage « Etant donné – Quand – Alors »
Cette représentation des scénarios, typique du BDD, est aussi connue sous le nom de langage de Gherkin. Typiquement, pour notre User Story, nous pourrions avoir les deux scénarios suivants dans ce langage :
Ces deux scénarios peuvent aussi être fusionnés si l’on préfère, l’important est de conserver une bonne lisibilité. Ces scénarios sont exécutables : l’implémentation du texte en mots d’actions d’automatisation (en keywords) permet d’obtenir un code de test exécutable pour l’intégration continue. Cette approche est outillée par de nombreux framework d’automatisation BDD tels que Cucumber ou SpecFlow, ou dans les plateformes de test en agile telles que Hiptest ou QASymphony, pour n’en citer que quelques-uns.
Scénarios sous une forme visuelle – Le pouvoir de l’image
La description visuelle du parcours applicatif au sein duquel la User Story est implémentée permet de produire les deux scénarios d’acceptation souhaités comme montré ci-dessous : en 1ère colonne le parcours applicatif, et ensuite les deux scénarios produits comme tests d’acceptation.
De façon similaire au textuel, les scénarios issus du visuel sont automatisés par une approche par mots d’action (Keywords) : « demande de remboursement », « vérification » et « remboursement et clôture du dossier » sont des keywords implémentés pour produire un code de tests automatisés. Le visuel permet aussi de produire la documentation de chaque test, par exemple pour alimenter le gestionnaire de tests pour une exécution manuelle, et pour relier ce test à la User Story en JIRA (ou dans tout autre gestionnaire de Backlog). Cette approche visuelle est prise en charge par les outils de conception de tests en agile tels que ARD de CA et Yest de Smartesting (les visuels précédant sont réalisés avec Yest).
Quels avantages réciproques du visuel et du textuel ?
Sur cette question, il y a d’abord une question de goût : préférez-vous un graphique ou du texte pour communiquer avec les utilisateurs Métier et maintenir une documentation vivante du produit ?
Une autre différence est dans le périmètre adressé : le parcours applicatif visuel décrit un workflow Métier lisible et donne une perspective couvrant généralement plusieurs User Story. C’est un atout important pour la documentation vivante car cela permet une visualisation globale et synthétique des comportements applicatifs. Un scénario textuel « Etant donné – Quand – Alors » vise à formaliser un scénario d’acceptation d’une User Story unique : la lecture globale est plus difficile car il faut passer en revue tous les scénarios concernés.
Pour finir, il reste la question : quelle différence entre ATDD et BDD ?
La compréhension la plus commune du BDD aujourd’hui est l’écriture des scénarios de test automatisés en Gherkin.
ATDD est une expression plus générale, recouvrant l’écriture des scénarios de test au moment de la définition des User Story et des critères d’acceptation associés, et l’utilisation de ces scénarios comme documentation vivante du produit. La scénarisation visuelle réalisée par le testeur agile au moment du raffinement du besoin est une approche typiquement ATDD permettant l’expression de workflows Métier (documentation vivante du produit) exécutables sous la forme de tests d’acceptation et de non-régression.
Ces approches sont au cœur de la transformation actuelle des pratiques du test, comme le montre la Journée Française des Tests Logiciels – JFTL 2018, avec plusieurs présentations et retours d’expérience sur ces techniques.
Une réponse