Un guide rapide pour la mise en œuvre de l’ATDD

Cet article fournit un guide rapide à toute personne intéressée par la mise en œuvre de l’ATDD dans ses équipes et ses projets. Il expose les avantages de suivre cette approche Agile en se basant sur mon expérience de première main au sein d’une équipe de développement de logiciels d’entreprise.

La collaboration est l’une des valeurs fondamentales de la méthodologie Agile. Une fois, alors que je travaillais sur un grand projet, j’ai remarqué un manque de collaboration entre les développeurs, les testeurs et les personnes soucieuses de l’entreprise ; un manque de clarté dans les exigences ; un élargissement fréquent de la portée des exigences ; un manque de visibilité en ce qui concerne les tests effectués ; et des défauts identifiés tardivement dans le cycle de vie du projet. Mais le plus important pour moi, c’est que personne n’avait la moindre idée de notre cadre d’automatisation, de sorte que tous les tests d’automatisation étaient écrits après que les fonctionnalités étaient développées et prêtes à être testées. À la suite de ces observations, j’ai commencé à chercher comment les gens s’attaquent à ce genre de problèmes. C’est ainsi que j’ai découvert que le développement piloté par les tests d’acceptation (ATDD) était l’une des approches utilisées pour atténuer bon nombre de ces problèmes. Il est souvent utilisé comme synonyme de Behavior Driven Development (BDD), Story Test Driven Development (SDD) et Specification By Example (SBE). La principale distinction de l’ATDD, par rapport aux autres approches agiles, est qu’elle vise à faire collaborer les développeurs, les testeurs, les gens d’affaires, les propriétaires de produits et les autres parties prenantes comme une seule unité et à créer une compréhension claire de ce qui doit être mis en œuvre.

Sur la base de ma propre expérience, je vais partager mes idées sur la façon dont les équipes peuvent mettre en œuvre l’ATDD dans leurs propres projets.

Le contexte

J’ai travaillé dans une grande entreprise qui avait un état d’esprit de startup, de sorte que toutes les idées innovantes et les commentaires étaient encouragés par l’équipe. Nous construisions rapidement des prototypes pour voir si une idée pouvait améliorer notre produit ou contribuer aux objectifs généraux de l’entreprise. J’étais le testeur principal d’une équipe de 25 membres, composée d’un scrum master, d’un responsable technique et de plusieurs analystes commerciaux, concepteurs, développeurs et testeurs. En raison de la culture de l’innovation, le chaos régnait souvent au sein de l’équipe, avec des changements fréquents dans les exigences des fonctionnalités, des individus travaillant dans des environnements cloisonnés et un moral d’équipe au plus bas. Cela me préoccupait, alors je me suis porté volontaire pour aider à trouver une résolution à ces points douloureux, ce qui m’a conduit à l’ATDD.

Tous mes apprentissages et mon expérience avec l’ATDD peuvent être catégorisés dans les 3 étapes ci-dessous.

Le cycle de mise en œuvre d’ATDD

Créé par Raj Subramanian

Étape 1 – Formation et expérimentation

Il existe de nombreuses façons d’aborder les tâches, surtout si l’on considère les expériences des individus travaillant dans différentes équipes agiles à l’intérieur et à l’extérieur de leurs organisations actuelles. Afin d’apporter une compréhension commune et partagée des objectifs de l’équipe et de l’organisation, il est important de fournir la formation appropriée. En ce qui concerne spécifiquement l’ATDD, elle devrait inclure les buts, les objectifs, les attentes et les informations sur les résultats qui découleront de l’utilisation de cette approche. Après la formation, il est important de commencer par une mise en œuvre à petite échelle afin d’essayer différentes choses et de recevoir un retour itératif.

Par exemple, après avoir fait des recherches sur l’ATDD, j’ai expliqué aux différentes parties prenantes pourquoi nous devions explorer cette approche et quels avantages nous en retirerions. J’ai souligné quelques-uns des points positifs possibles, tels qu’une collaboration accrue au sein de l’équipe, une meilleure clarification des exigences, une identification plus rapide des défauts dans le cycle de vie du développement logiciel (SDLC), une visibilité accrue et une utilisation plus précoce de l’automatisation dans le SDLC, ainsi que la participation de toute l’équipe à la définition de critères d’acceptation clairs.

Lors de ma discussion avec les parties prenantes, j’ai souligné que cela nécessiterait une certaine expérimentation, mais sans l’essayer, nous ne pourrions jamais connaître ses avantages. Après quelques longues discussions, nous avons décidé de diviser l’équipe initiale de 25 personnes en 2 équipes plus petites : L’équipe A était composée de 12 personnes et mettrait en œuvre l’ATDD. L’équipe B comptait les 13 personnes restantes, et elle continuerait à faire ce qu’elle faisait déjà.

J’ai planifié un atelier de formation de 2 jours pour l’équipe A en apprenant ce qu’était l’ATDD, en déterminant quels concepts avaient du sens dans le contexte de notre projet, et comment nous pouvions tirer parti de l’automatisation tout au long de ce processus. J’ai inclus un mélange d’exercices théoriques et pratiques dans la formation. Certains des exercices sont ci-dessous:

• Comment écrire des déclarations Gherkin – Given/When/Then (GWT)
• Quels sont les attributs clés d’une bonne user story?
• Une démonstration de notre cadre d’automatisation, y compris à la fois comment il fonctionnait et comment il était structuré. Il y avait également des exercices sur la façon d’écrire un code de test d’automatisation simple en équipe. Avant l’atelier, un membre de l’équipe et moi avons modifié notre cadre d’automatisation pour qu’il soit en phase avec l’approche ATDD. Nous avons utilisé le plugin Cucumber avec Java et Appium pour notre cadre d’automatisation.

Source

Étape 2 – Accroître la visibilité

Lorsqu’un projet vit à travers plusieurs sprints, il est facile de perdre le fil des différents processus qui doivent être suivis. La clé est donc de rendre les buts, les objectifs et les attentes visibles pour toute l’équipe.

Lorsque nous avons commencé à utiliser l’ATDD, j’ai commencé par simplement écrire chacun des processus quotidiens qui devraient être suivis sur un tableau blanc, que j’ai placé là où notre équipe avait ses réunions quotidiennes de stand-up. Pour chaque histoire d’utilisateur, j’ai ajouté une liste de contrôle des éléments qui devaient être réalisés avant que l’histoire ne soit considérée comme complète. De cette façon, il n’y avait aucune ambiguïté sur les processus ATDD à suivre. L’un de ces éléments était une réunion de lancement, au cours de laquelle le développeur, le testeur et les responsables commerciaux discutaient des exigences en équipe, identifiaient celles qui pouvaient être automatisées et définissaient les critères d’acceptation de l’histoire au format GWT. Un autre élément de la liste de contrôle était le handoff QA-Dev, au cours duquel le développeur montrait au testeur, par le biais d’une démonstration rapide ou d’une discussion, comment les exigences avaient été remplies et quels tests unitaires avaient été écrits dans le cadre de l’histoire. Grâce à ce transfert, le testeur a appris quelles zones n’étaient pas couvertes par les tests unitaires et a acquis une meilleure compréhension de la fonctionnalité mise en œuvre, ce qui a permis d’améliorer la couverture des tests. Les éléments de la liste de contrôle étaient parfois évidents, mais il était bon qu’ils soient clairement énoncés. Nous en avons inclus un pour nous assurer que tous les défauts associés à la story étaient fermés ; un autre était l’approbation finale par une personne de l’entreprise après avoir visionné une démo, garantissant que la fonctionnalité était construite conformément aux exigences et aux attentes précédemment établies.

Nous avons également commencé à avoir un « Process Hawk ». C’était un membre individuel de l’équipe ; il pouvait s’agir d’un scrum master, d’un chef de projet ou de toute personne qui s’assurerait que l’équipe suivrait le processus. Dans mon cas, c’était un autre testeur senior au sein de l’équipe ; lui et moi rappelions régulièrement à tout le monde de suivre le processus ATDD dans toutes les réunions, y compris le standup, la planification, la rétrospective et d’autres réunions d’équipe.

Étape 3- Apprentissage itératif et feedback

Avoir une boucle de feedback constante est crucial dans la mise en œuvre de toute approche agile, y compris ATDD. Avoir des réunions rétrospectives hebdomadaires ou bihebdomadaires avec l’ensemble de l’équipe est un moyen important de savoir quelles parties du processus profitent réellement à l’équipe, et lesquelles peuvent avoir besoin d’être modifiées. Comme nous le savons déjà, ce qui n’aide pas l’équipe entraîne une perte de temps et d’efforts. Comme le déclare Brian Tracy, auteur de Eat That Frog! : 21 Great Ways to Stop Procrastinating and Get More Done in Less Time, « L’une des pires utilisations du temps est de faire très bien quelque chose qui n’a pas besoin d’être fait du tout. »

À l’ère actuelle des technologies de l’information, les organisations ne peuvent pas se permettre de perdre du temps et de l’énergie dans des approches inefficaces ; nous devons plutôt mettre en place des processus allégés et efficaces. Cela rejoint le principe de l’apprentissage validé du Lean Startup : le cycle Construire, Mesurer, Apprendre.

Avec cela en tête, j’ai commencé à avoir des réunions de 30 minutes chaque jeudi avec l’équipe A pour vérifier comment l’équipe se débrouille avec le nouveau processus. C’était un bon moyen de jauger les changements à apporter en fonction des réactions de l’équipe. Cette réunion se tenait séparément de la réunion de rétrospective qui avait lieu à la fin des sprints de deux semaines. Cette approche a permis d’obtenir un feedback continu de la part de l’équipe, ce qui nous a permis d’apporter des changements immédiats et efficaces. Le retour d’information ne provenait pas uniquement des vérifications hebdomadaires du processus ; les réunions quotidiennes se sont également révélées être une source précieuse d’informations. Les mises à jour et les discussions individuelles des membres de l’équipe ont permis de découvrir des signaux d’alarme liés au processus, et nous avons pu y remédier immédiatement avant qu’ils n’affectent le reste de l’équipe.

Résumé

En suivant le cycle de mise en œuvre d’ATDD, l’équipe A a commencé à constater des différences considérables dans le moral de l’équipe, la collaboration et les exigences.

Moral de l’équipe

Tout le monde a commencé à travailler en équipe et s’est senti responsabilisé. Chaque personne s’est approprié une histoire du début à la fin. Il/elle s’assurait que l’histoire avait toutes les informations nécessaires pour commencer le travail de développement et de test. Le membre de l’équipe a également veillé à ce que tous les suivis liés à l’histoire soient effectués. Enfin, cette personne était chargée de présenter l’histoire à toutes les parties prenantes à la fin du sprint. Ce sentiment d’appropriation a considérablement renforcé le moral de l’équipe.

Collaboration

Les réunions de lancement ont réuni le responsable métier, le développeur et le testeur, afin de développer une compréhension commune de la story utilisateur. Le handoff QA-Dev, qui a eu lieu avant de pousser la construction vers les serveurs QA, a aidé le développeur et le testeur à savoir quels tests seraient effectués dans le cadre de l’histoire, et a apporté une meilleure compréhension de la fonctionnalité mise en œuvre. L’automatisation a gagné en visibilité, puisque l’ensemble de l’équipe s’est approprié le projet, et non plus seulement les testeurs. Enfin, lors des réunions de planification, toute l’équipe a discuté de l’histoire ensemble, ce qui a généré davantage d’idées, de questions et de discussions. L’équipe a décidé d’organiser des séances de coaching entre pairs pour apprendre les uns des autres, les testeurs ont commencé à effectuer des tests exploratoires en binôme et des déjeuners d’apprentissage ont été organisés par différents membres de l’équipe pour discuter de divers sujets liés à la technologie. Toutes ces choses ont conduit à l’amélioration de la collaboration globale de l’équipe.

Les exigences

L’un des principaux problèmes de nos processus précédents était les changements fréquents dans les exigences et la dérive de la portée. Avec l’approche ATDD, il était impératif qu’une fois que le développeur commençait à travailler sur une histoire, les exigences devenaient verrouillées. Toute modification doit être classée par ordre de priorité parmi les autres histoires à venir et ajoutée aux sprints à venir. Cela a réduit la charge de travail des développeurs et des testeurs, et a empêché les parties prenantes d’avoir des attentes irréalistes concernant les fonctionnalités terminées.

Après avoir constaté toutes les améliorations ci-dessus, l’équipe B a commencé à mettre en œuvre l’ATDD également. Par conséquent, toute l’équipe initiale a utilisé cette approche après une expérimentation et un retour d’information réguliers.

Conclusion

Je recommande l’approche d’ATDD, et elle s’aligne sur le « Shift Left Paradigm » qui stipule que le développement et les tests devraient commencer le plus tôt possible dans le SDLC. Elle a apporté plus de visibilité dans l’automatisation, car nous avons commencé à écrire des tests automatisés au début du SDLC, ce qui a augmenté la collaboration au sein de l’équipe.

Source

Rappellez-vous, l’ATDD n’est pas une solution « taille unique ». C’était l’approche agile qui avait le plus de sens dans le contexte de mon projet, mais il existe diverses autres façons d’améliorer les processus dans les équipes. J’ai utilisé cette approche parce qu’elle met l’accent sur de meilleurs tests d’acceptation, mais surtout parce qu’elle met l’accent sur la collaboration. La pièce de collaboration est une partie intégrante de cette approche, et je crois qu’elle est la plus précieuse.

À propos de l’auteur

Raj Subrameyer est un stratège de carrière en technologie qui se concentre sur l’aide aux personnes pour décrocher l’emploi de leurs rêves et devenir des leaders prospères. Il se passionne pour guider les professionnels à maximiser leurs opportunités et à découvrir leur zone de génie. Il utilise son expérience dans l’industrie technologique pour faire des recherches, parler et écrire sur la façon dont nous pouvons adopter la technologie et devenir des citoyens numériques à part entière. Il est un orateur très demandé lors de diverses conférences et a été présenté dans de nombreux podcasts et publications, notamment CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success et The Good Men Project. Il est également l’auteur du nouveau livre « Skyrocket Your Career ». Ses domaines d’expertise sont l’avancement de carrière, le leadership, la motivation, la productivité et l’entrepreneuriat. Pendant son temps libre, il aime voyager et déguster de la bière artisanale. Vous pouvez trouver plus d’informations sur la façon dont il sert les gens sur son site Web.