Le développement basé sur les tests d'acceptation : premier survol

Depuis les dernières années, on entend de plus en plus parler de l’agilité en intelligence d’affaires. Plusieurs cadres agiles existent, mais SCRUM est le plus répendu dans le domaine. Étant moi-même SCRUM master, j’ai décidé d’explorer de nouvelles approches afin de pouvoir les intégrer dans mes mandats.

Cet article de blogue est le premier d’une série traitant du cadre de développement agile basé sur les tests d’acceptations (Acceptance test driven development, ATDD). Cette première partie a pour but de survoler ce cadre de développement en expliquant brièvement chacune des étapes.

Qu’est-ce que l’ATDD?

Tout comme le cadre Scrum, le développement par tests d'acceptation est un cadre de développement de logiciel qui utilise des principes lean et agile. Différent du développement basé sur les tests (TDD) qui vise plutôt les tests unitaires, l’ATDD est un cadre technique avec un focus de plus haut niveau, qui a comme mission de s’assurer que l’ensemble de l’équipe comprend bien les requis. De plus, l’ATDD a comme objectif de réduire le temps de développement ainsi que d’augmenter la qualité des fonctionnalités en minimisant les allers et retours entre les tests et le développement. Contrairement au développement « typique », l’ATDD propose d’utiliser l’élaboration des tests d’acceptations en guise de phase de prise des besoins et par le fait même, de définir la complétion de chacune des fonctionnalités . En procédant de cette façon, l’équipe (client, développeurs, testeurs) s’assure d’avoir une compréhension complète et partagée de chacune des fonctionnalités à développer.

Les acteurs de l’ATDD

Dans cette méthodologie, l’équipe est composée de 3 acteurs : le client (« product owner », analyste d’affaires, expert de sujet), les développeurs et les testeurs. Chacun a un rôle spécifique à jouer, voir le tableau 1. Il est à noter que le rôle de testeur et de développeur peut être réalisé par seulement une personne. De plus, il peut arriver, dans de petits projets, que le client ait une tâche de développement ou de testeur. Bien que chaque acteur joue un rôle spécifique, tous travaillent vers un objectif commun, un livrable de qualité.

Le processus de L’ATDD

Maintenant que l’on sait ce qu’est l’ATDD et quels sont les acteurs principaux, nous allons voir en détails son processus. Celui-ci est divisé en 5 grandes étapes:

1. La charte de projet
2. Les fonctionnalités
3. Les histoires
4. Les scénarios
5. Les tests
   
   

Charte de projet

La charte projet est composée de quatre items qui guideront le développement tout au long du projet (tableau 2).

Fonctionnalités

Une fois que la charte de projet est établie, c’est l’heure de définir les requis de hauts niveaux. Cette étape se veut une liste des fonctionnalités désirées par le client afin d’accomplir les objectifs définis dans la charte. Toute fonctionnalité ne répondant pas à un objectif doit être mise de côté. Pour chacune des fonctionnalités, l’équipe doit définir un critère d’acceptation.

Histoires
Par la suite, les fonctionnalités doivent être décomposées en histoires aussi appelées « stories ». Comme dans la majorité des cadres agiles, chaque histoire doit respecter la règle «INVEST »: Indépendante, négociable, valorisante, estimable, petite (« Small ») et testable. Chacunes des histoires doivent être évaluées sous deux angles : la valeur apportée et l’effort de réalisation.

Scénarios

Lorsque les histoires sont définies, on doit en faire des scénarios. L’approche généralement utilisée pour construire des scénarios est la technique par use case (cas d’utilisation). Celle-ci permet de capturer des comportements, des séquences d’évènements et des réactions entre le logiciel et l’utilisateur, sans avoir à décrire la façon dont celui-ci doit être implémenté. Il existe différentes façons de documenter un cas d’utilisation, le but ici est de documenter le détail de chacune des histoires. Les conditions de départ et de fin, le trajet principal, les exceptions et les alternatives sont des éléments que l’on se doit de documenter dans les cas d’utilisations.

Tests

À partir des scénarios, nous devons maintenant découler des tests d’acceptations. Dans un monde idéal, les tests doivent être écrits avant le début du développement. Cependant il n’est pas impossible de découvrir de nouveaux tests en cours de route.

En bref

L’ATDD offre une plateforme de communication des besoins entre le client, les développeurs et les testeurs via l'élaboration des tests d'acceptation. Ceux-ci doivent être des tests compris et définis par les besoins des utilisateurs. Bien sûr, ce cadre est principalement utilisé dans un projet de système transactionnel, mais plusieurs items peuvent être utilisés afin d’augmenter la performance d’une équipe projet.

Dans un prochain article de blogue, je parlerai de la façon dont il est possible d’intégrer ce cadre dans le monde de l’Intelligence d’affaires en synergie avec le cadre SCRUM.