Le test dans une équipe agile / Scrum (Agile Testing)
Vložit
- čas přidán 31. 03. 2024
- 🎁 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 !)
Ça se passe comment les tests dans ton équipe ? Raconte-nous !
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.
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 ?
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 ?
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: czcams.com/video/vPkdSBkpwpE/video.html&ab_channel=ScrumLife-Lean%2CAgile%2CKanban
@@ScrumLife Super merci pour cette réponse très claire et ça aide pas mal a avancer et se projeter :)
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 🙂
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é.
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
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.
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).
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
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.
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+
@@fernandodebritocerqueira3407 c est ce qu on fait la ou je suis.
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".
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