Le test dans une équipe agile / Scrum (Agile Testing)

🎁 Le guide du Scrum Master compétent 👉 sl.run/ShBgtc
On regarde une vidéo de Alec Roy ‪@alec-agile-gardener‬ dans laquelle il nous parle des activités de test au sein d'une équipe de développement logiciel. On a évidemment plein de belles choses à ajouter sur le sujet ! #TestAgile #AgileTesting #ScrumLife
💜️ Rejoins la communauté Scrum Life 👉 sl.run/e2LBRw (c'est gratuit !)

[@ScrumLife]

Ça se passe comment les tests dans ton équipe ? Raconte-nous !

[@thegreatdyl]

J'ai fait le diplome ingé développeur application et chef de projet SI à l'institut G4 en alternance) et j'ai eu des cours sur la qualité: assurance qualité, plan d'assurance qualité ... Mais j'ai aussi eu des projets simulés complet en agile et en cycle en V avec toujours une composante qualité avec des livrables associés ! Certe le diplôme est estampillé "Chef de Projet" mais c'est surtout la 4e et 5e année ou ces sujets sont approfondies, les 3 premieres années sont très orientées développement. Une formation très complète ! Au passage merci pour vos vidéos ! Un vrai complément pertinent à tout ce que j'ai pu apprendre en cours et en entreprise sur l'agilité

[@NicolasPAZDYKA]

Bonjour ! Super intéressant, merci pour la vidéo. Chez nous, le PO écrit les tests d'acceptabilité (Scénario + jeu de donnée) et les lies à l'US (nos US se présentent sous la forme : Description, Règles métiers, Test d'acceptabilité). Une fois l'US développée, le PO joue les tests avec le support (pour qu'il intègre rapidement la feature) et fait ses retours à l'équipe de réalisations. On fait du scrum depuis 1an maintenant avec une petite équipe donc on essaye des choses.

[@ScrumLife]

Bonjour @NicolasPAZDYKA ! 😊 Merci pour ton retour, et c'est génial de voir que vous prenez l’initiative de tester différentes approches avec votre équipe ! 👏 L’implication du PO dans la rédaction des tests d'acceptabilité et leurs validations est effectivement cruciale pour s’assurer que l'US répond bien aux attentes. Petite question : comment votre équipe de réalisation réagit-elle aux retours de votre PO après les tests ? Est-ce que cela permet d'améliorer continuellement votre processus ? Hâte d’en savoir plus sur votre expérience et bon Scrum ! 💪 Robin

[@komimarcatsou1871]

Merci pour cette réflexion. Je pense que le sujet mérite un livre en entier ou une conférence dédiée. Moi je suis sur un projet data et le problème de réduction de la boucle de feedback est amplifié.

[@ScrumLife]

Ravi que ça t'ait parlé ! Effectivement, plonger dans les tests Agile, surtout sur un projet data, c'est tout un monde. A propos de livre, je te conseille "Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin et Janet Gregory. C'est un must-read pour moi... tu me diras ce que tu en penses ! Robin

[@FRANTZDEGRIGNY]

J'ai donné récemment une conférence sur le sujet. Tu peux trouver le replay (et du contenu à télécharger) sur le blog de Conserto.

[@ScrumLife]

Merci pour ton commentaire @komimarcatsou1871 ! Content que la réflexion t’ait interpelé. 😃 Effectivement, réduire la boucle de feedback est un défi majeur, surtout dans les projets data où les cycles peuvent être particulièrement longs. As-tu déjà tenté des approches spécifiques pour raccourcir ces boucles ? Je suis curieux de savoir comment tu t'y prends ! Je te rejoindre sur l'idée d'une conférence dédiée. C’est une excellente suggestion et je la note pour de futures vidéos ou même un event live ! À bientôt sur Scrum Life, et bon courage avec ton projet ! Robin 🚀

[@TomC-mq3oj]

Hello, merci pour le partage très intéressant. Je me demandais du coup, dans vos expériences dans les organisations qui tendent vers ce modèle, que deviennent les testeurs ?

[@ScrumLife]

Salut ! J'en parle dans plusieurs de mes confs autour du rôle de "testeur agile" ou sur la transformation agile du point de vue du département QA, ainsi que dans quelques articles. En résumé : le rôle de testeur traditionnel, essentiellement manuel et centré sur l'exécution, n'a que peu de valeur et devrait disparaitre. Dans tous les cas ce n'est pas une piste de carrière que je recommande. Se pose donc la question à la fois de ce qu'il se passe dans les équipes, mais aussi de ce que deviennent ces personnes en termes de carrière. Côté carrière de testeur : - On peut creuser sa casquette automaticien et se rendre compte qu'en réalité, on est un développeur. Même si l'on est spécialisé dans la manipulation de frameworks de test, cela reste du développement logiciel. De mon expérience, c'est principalement le syndrome de l'imposteur qui retient ces testeur de réaliser qu'ils sont bels et bien des développeurs et qu'ils doivent l'assumer en tant que tel -- et probablement qu'ils sont meilleurs que la majorité des juniors, qui n'ont justement aucune notion de test ! - On peut vouloir rester avec la casquette du test et devenir un "testeur agile" -- le nom n'est pas super mais c'est le consensus de l'industrie pour parler de ce rôle qui se focalise avant tout sur la stratégie de test et la testabilité, tout en apportant ses expertises d'exploration du produit et de gestion de risque. Le travail repose sur la mise en oeuvre du "shift left" (en amont du développement : stratégie de test, définition des cas de test) et du "shift right" (en aval du déploiement : monitoring, collecte et exploitation de feedbacks produit), pour se séparer au maximum de l'étape "validation" entre le développement et le déploiement qui est avant tout une responsabilité collective de l'équipe. C'est un métier passionnant, qu'on peut valoriser en termes de salaires comme celui d'un bon développeur. - On peut aller encore un peu plus loin dans la démarche du "testeur agile" et devenir coach sur ces enjeux de test et de qualité, en étant un acteur transverse ou du moins transitoire dans les équipes. On a pour rôle de former les équipes à être autonomes sur leurs enjeux de qualité, quand le "testeur agile" continue d'apporter de la valeur au sein de l'équipe. On pourrait probablement appeler aussi ce rôle coach agile selon comment on veut se positionner. De même certain testeur se découvrent une passion pour l'agilité et deviennent Scrum Master : de mon expérience c'est assez pertinent. - Enfin, on peut aussi partir sur d'autres rôles moins "techniques". On pense souvent au Product Owner, ce qui est une suite logique pour un profil fondamentalement orienté sur l'expérience client tout en ayant un véritable vernis technique ; attention tout de même à bien développer sa casquette Product Management pour bien occuper ce rôle. De manière similaire je fais beaucoup de parallèles avec des rôles qui tournent autour de l'UX, d'une car il est question d'utilisation du produit, et de deux car la démarche intellectuelle repose sur le test : on veut valider ou invalider des hypothèses. Côté équipe : - Shift Left : le travail avec le testeur intervient surtout en amont du développement, pour définir une stratégie de test qui évalue les impacts et gère les risques, et pour définir les cas de test qu'il faudrait faire passer pour valider le développement. C'est la testabilité : interdit de commencer le développement si l'on ne sait pas comment on testera ! Au-delà d'être une approche fondamentalement sensée et qui encourage les discussions et la collaboration tôt plutôt que trop tard, cela ouvre également les portes à des démarches de développement pilotées par des tests automatisées, de type Test First ou ATDD. - Plus de validation réservée au testeur (ou au PO) : soit les tests d'acceptation sont automatisées et il "suffit" de les faire passer en succès (ainsi que la suite de non-régression, elle aussi automatisée), soit il reste du test manuel et dans ce cas il s'agit de tâches d'équipes, que n'importe qui dans l'équipe peut et doit prendre. En effet, via le Shift Left, on aura déjà défini les scénarios de test. Si on manque de compétences ou de moyens pour tester, l'équipe travaille sur ces points (par exemple détail de procédures dans le Wiki de l'entreprise, ou partage des accès aux outils et plateformes à toute l'équipe et non pas juste aux testeurs) pour que n'importe qui puisse s'en charger. - Dans tout ça, le testeur prend du recul pour contribuer en premier aux tâches où il aura le plus de valeur ajoutée : la conception du produit, la stratégie de test, les moyens de test, etc. Il contribue également au quotidien de l'équipe mais jamais comme un goulot d'étranglement. Au contraire, il "coach" l'équipe pour qu'elle soit autonome dans sa capacité à tester si elle ne l'est pas déjà. Est-ce que cela t'aide ? -- JP

....et on évoque cet échange dans le live du jeudi: kzbin.info/www/bejne/rIHOlYZ4oNWqpqc&ab_channel=ScrumLife-Lean%2CAgile%2CKanban

[@TomC-mq3oj]

@@ScrumLife Super merci pour cette réponse très claire et ça aide pas mal a avancer et se projeter :)

[@ScrumLife]

Salut @TomC-mq3oj ! Merci beaucoup pour ton commentaire et ta question pertinente. Dans les organisations qui adoptent les approches agiles, le rôle des testeurs évolue significativement. En Scrum, par exemple, les testeurs ne disparaissent pas, mais leur mission s'intègre davantage à l'équipe Scrum. Ils travaillent main dans la main avec les développeurs dès le début du Sprint, en participant à l'élaboration des critères de définition de fini (Definition of Done) et en s'assurant que chaque incrément de produit est testé et prêt pour la livraison potentielle. D'ailleurs, on voit souvent émerger la notion de "Développeur de Tests", où les compétences des testeurs et des développeurs fusionnent pour améliorer la qualité du produit de manière continue et collaborative. As-tu déjà observé ce type de transformation dans ton organisation ou ailleurs ? Ravi de te lire et d'échanger encore plus sur ce sujet passionnant ! 🚀 À bientôt, Robin

[@yarazakaria7994]

Dans mes équipes c'est les "BA" et PO qui testent. Quand j'ai lancé l'idée que les devs testent aussi, le retour était qu'ils n'ont pas les compréhensions fonctionnelles globales et détaillés pour le faire. Qu'en pensez-vous? Et la notion de context switching est très intéressante, comment pouvoir l'illustrer à l'équipe ? avez vous un serious game pour démontrer que c'est coûteux ?

[@ScrumLife]

Salut @yarazakaria7994 ! Merci pour ton commentaire ! Alors, concernant les devs et les tests, je pense que ton équipe gagnerait à favoriser une mindset collaboratif. Les Tests-Driven Development (TDD) et Behavior-Driven Development (BDD) sont justement des pratiques qui encouragent les développeurs à comprendre davantage le domaine fonctionnel et à participer activement aux tests. Impliquer les devs dans le processus de test pourrait non seulement améliorer la qualité du code mais aussi réduire les allers-retours avec les BA et les PO. Pour illustrer la notion de context switching, il existe effectivement des serious games très efficaces. Un de mes préférés est le "Nombre de tâches par Minute (NTPM)". Ce jeu simple aide à montrer à quel point le fait de changer fréquemment de tâche peut ralentir le travail et impacter la qualité. Tu peux trouver des ressources et des exemples de ce jeu en fouillant un peu sur internet ou en te rapprochant de coachs agiles expérimentés. Cette approche pourrait vraiment faire bouger les choses dans ton équipe. N’hésite pas à partager leurs réactions avec nous ! À bientôt et reste agile, Robin 🚀

[@sihembrahimi7099]

Bonjour, ça m'est arrivé de travailler avec des développeurs qui échangent avec les testeurs pour remédier au plus tôt aux bugs détectés. Et ne se retrouvait jamais dans un goulot d'étranglement 🙂

[@ScrumLife]

Merci pour ton commentaire @sihembrahimi7099 ! 🎉 C'est génial de voir des équipes qui collaborent si étroitement et qui parviennent à éviter les goulots d'étranglement. C'est exactement ce que les approches agiles, comme Scrum ou Kanban, cherchent à encourager : fluidifier les processus et réduire les interruptions inutiles. Dis-moi, quels outils ou techniques utilisez-vous pour maintenir cette communication et cette coopération fluide entre développeurs et testeurs ? Je suis curieux de savoir si vous avez des pratiques spécifiques qui aident à atteindre ce niveau d'efficacité. À très vite dans les commentaires ! Robin 🚀

[@sophiebukowski6802]

Ce serai intéressant d’interroger des personnes qui travaillent sur les programmes des "écoles de testeurs" (de management, de gestion de projet aussi 😅...) pour comprendre pourquoi est ce qu’il semble que, encore aujourd'hui, les étudiants sortent avec tellement peu de notions (que j’appelerai, pour être très generique) "agiles".

[@ScrumLife]

Salut Sophie ! Excellente idée ! Explorer directement avec les responsables des programmes pourrait vraiment nous éclairer sur l'écart entre les compétences enseignées et les besoins réels du monde du développement logiciel. Ca peut donner une idée d'interview ;) ... voir de reportage ! A bientôt ! Robin

[@ScrumLife]

Bonjour @sophiebukowski6802, Quelle excellente suggestion ! Tu touches un point crucial : la formation initiale de nos futurs professionnels en gestion de projet et en management est souvent déconnectée des réalités et des besoins de l'agilité en entreprise. Interroger les responsables des programmes des "écoles de testeurs" et autres formations similaires pourrait vraiment apporter des éclairages intéressants. Merci pour ton commentaire constructif, ça donne envie de creuser ce sujet. Tu as déjà remarqué des initiatives qui vont dans ce sens ou des écoles qui s’adaptent mieux à l’agilité ? Scrumement vôtre, Robin

[@pascalmanucci6572]

Plusieurs remarques, en particulier sur les tests unitaire et la qualité non-négociable. Tout d'abord, une architecture (en particulier sur du legacy) peut-être "non-testable" : de gros efforts préalables sont nécessaires pour pouvoir mettre en oeuvre une démarche de tests. L'autre sujet est la nécessité d'avoir une approche de "livrer de la valeur" et pas "des features" : en effet au début d'une stratégie de test agile, la "productivité" sera moins importante et les parties prenantes (surtout si elles n'ont pas la bonne culture) auront l'impression de "faire un chèque en blanc". Dit autrement "livrer moins de volume" et plus de qualité n'est accepté que si "le peu qui est livré" a un sens métier immédiat et une forte valeur/impact (notez les guillemets).

[@ScrumLife]

Oui ! Tout à fait, merci de la précision, très bien expliqué 👍 J'imagine que ce fameux "legacy" tant redouté, c'est quelque chose que tu as connu à plusieurs reprises ? -- JP

[@pascalmanucci6572]

En fait, ce fameux legacy, il est assez inévitable dans toutes les entreprises qui ont du logiciel ancien : c'est assez inévitable, avec plus ou moins de dette, il faut l'accepter je pense. Il génère son lot de dette organisationnelle également et ses "barrières de Chesterton". La bonne nouvelle c'est que si ce legacy existe, c'est que ces entreprises ont survécu, la moins bonne c'est qu'il faut le traiter. Il y a une vraie complexité à le traiter, cela prend du temps, beaucoup d'efforts de transformation, des enjeux de sécurité psychologique etc etc ... C'est quelque chose que j'ai observé systématique à plus ou moins grande échelle sur toutes les boites assez anciennes.

[@fernandodebritocerqueira3407]

Salut @@pascalmanucci6572 , faire du test unitaire sur du code legacy ça peut rapidement etre une galère (voire très souvent impossible). Mais sur du legacy on peut tout de même faire du Golden Master Testing ce qui te permet de faire du test de non régression assez rapidement et sécuriser ta refactorisation ... et n'oublions pas le code d'aujourd'hui s'il n'est pas testé automatiquement c'est potentiellement le legacy de demain ;-) A+

[@pascalmanucci6572]

@@fernandodebritocerqueira3407 c est ce qu on fait la ou je suis.

[@ScrumLife]

Salut Pascal ! Merci pour ton commentaire très réfléchi et pertinent. Tu mets en lumière deux challenges classiques en agilité : l'architecture legacy et la perception de la valeur livrée. Sur le premier point, oui, transformer une architecture "non-testable" en un environnement propice aux tests unitaires peut nécessiter des efforts considérables. Cela peut impliquer des refactorings, des audits de code et une implication accrue des équipes techniques et métiers. Tu touches aussi un point essentiel avec la notion de "livrer de la valeur" plutôt que des "features". En phase de transition vers une culture de test agile, il est crucial de communiquer l'importance de la qualité à toutes les parties prenantes. La notion de "chèque en blanc" peut être atténuée en démontrant la valeur métier immédiate des livraisons, même si elles sont réduites en volume. En effet, une fonctionnalité de haute qualité et à fort impact peut souvent surpasser une multitude de features moins significatives. Quel a été ton plus grand défi lors de la mise en place d'une démarche de tests dans un environnement legacy ? Partage ton expérience, ça pourrait vraiment enrichir la discussion ici ! Robin

[@Maya-yr4kh]

C'est à dire bye bye les testeurs!!!