Le testeur Agile en Scrum - Scrum Life 26

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/1hcZ3K

[@lisacrispin8791]

OMG! So much spot-on information in such a short video! I love the props and your role-playing that make it so fun, too! I particularly value your observations about the need to *maintain* automated tests. I'm not a fan of "shift left" and "shift right" the way most people use them, but you are using them to show that testers add value throughout the process and beyond delivery to production - perfect. You are illustrating a lot of principles of what Alan Page and Brent Jensen call "modern testing", are you familiar with those? I believe this is the future of testing. And pair testing - yeah!!!! This applies way beyond only Scrum. But you make a good point about how Scrum supports the cross-functional team - all the skills needed on one delivery team.

[@abdoulifeshare]

Ce qu'on à fait nous c'est qu'on a le Testeur qui intègre l'équipe Scrum Team biensure et : - il assiste à la rédaction des DoD, - il teste au quotidien et challenge la version build courante, - pour chacune des US finis il commence les tests sans attendre (on a une colonne "Review" après la colone "In progress" et avant la colonne "Done", qu'il suit quotidiennement durant le daily ) - Il travaille en parallèle sur l'automatisation des tests du "sprint -1" - On fait le freeze code 3 jours avant la fin du sprint pour le laisser faire des tests d'intégration Merci pour tes vidéos que je trouve intéressantes, Bravo!

[@nadhhely1285]

Merci beaucoup pour votre commentaire je viens d'intégrer une structure où je dois à la fois être scrum master et faire les tests et j'avoue que j'avais du mal à trouver mes taches dans l'équipe de dev

[@johannharguindeguy4940]

Quand je penses que j'ai rêvé de vivre ce rôle de testeur, au sein d'une équipe avec ce souhait d'accompagner où je me suis retrouvé en bout de chaine à certes décrivant des KdT en amont mais.avec l'attente du go pour exécution plutôt qu'agir AVEC L'EQUIPE... Merci pour cette vidéo qui redonne espoir.

[@ScrumLife]

C'est l'avenir du métier de testeur 🙂

[@mickaelarazor5260]

Il faut souvent de la conduite au changement pour arriver là. Mais c'est tout bénéf pour tout le monde.

[@r33iv44x]

Je trouve intéressant l’idée de faire intervenir le testeur dans l’interprétation des observations issues de la supervision, et de jouer ainsi sur la complémentarité entre test et supervision.

[@benoitgantaume]

Au top ta vidéo! C'était riche, merci. Pas de QA de mon côté. Je préfère mettre de l'énergie dans l'automatisation des tests d'acceptance. Mais ta vidéo me fait reconsidérer ma position. 😀

[@user-us9bx1iz3n]

Nous on a des testeurs dans nos équipes et on fait ce qu'il ne faut pas faire, tester à la fin du sprint (pas le temps de finir, décalage de test, etc.)

[@sabrinavigil8360]

Super vidéo! J’ai l’impression de voir des similitudes entre testeur et designer UX/UI, je suis intéressée par ton avis le métier de designer, le sujet d’une prochaine vidéo peut-être ? 🤞

[@peewee3951]

Merci pour cette vidéo et la valorisation du métier de testeur. J'en tendance à dire que le testeur ralentit le projet pour que celui-ci ait une qualité meilleur. Ainsi au bout du compte, ce ralentissement est un gain de temps. Il le ralentit car il doit exécuter les tests, et c'est en cours de ceux-ci que les développeurs qui ont commencé une autre fonctionnalité, ont les retours par les anomalies et donc doivent se replonger dans leur code et les corriger. Quand le nombre d'anomalies est trop important, ils font généralement plus attention à leur code et la criticité des anomalies diminue, ce qui satisfait tout le monde. Lors d'une expérience précédente, le responsable tests a, à mon sens, fait 2 erreurs majeurs : notre équipe n'était pas répartie au sein des équipes Agile, et le temps de sprint n'était pas calé avec les autres (1 semaine pour nous, 2 pour les dev+PO). Résultat : on passait notre temps à préparer les reporting, faire des réunions inutiles, et on travaillait au jour le jour avec ce qui était livré. Dans Jira, on avait nos US plus celles des 3 équipes. C'est ingérable et illisible. Et même par respect pour le chef de projet, j'avais l'impression de lui faire perdre du temps. L'introduction d'une équipe QA dans des projets qui n'en ont pas est à préparer minutieusement et avec une hiérarchie ouverte aux propositions (sinon, c'est la catastrophe assurée). Il faut préparer les axes de communication avec les équipes dèv et PO (par quelle manière on s'adresse à eux, leur préciser notre périmètre d'intervention), (n'oublions pas que les dèvs sortent parfois d'école et ne connaissent pas ou peu le métier de QA), préparer les outils de reporting pour la hiérarchie (quels chiffres, quel format, quelle fréquence), et modifier les process dans les outils (je pense notamment aux statuts des US et des anos pour savoir quand le testeur peut commencer son travail et avertir que celui-ci est terminer pour la phase suivante). Et surtout attention : le test automatique NE REMPLACE PAS le test fonctionnel.

[@ScrumLife]

Merci pour ce partage. Selon vous, que faudrait-il faire pour que le métier de testeur soit plus mis en avant ?

[@peewee3951]

@@ScrumLife Bonsoir, Quand j'ai commencé ce métier, le cycle en V était encore largement dominant et les testeurs étaient considérés déjà comme essentiels car il y en avait plusieurs équipes à des stades différents. On faisait partie intégrante du projet. Aujourd'hui, bien que l'agilité est apprise en études supérieures je suppose que le test est évoqué. Les élèves sont très bon en développement, ou ont des facilités de réflexion fonctionnelle pour être Business Analyst ou PO., Scrum Master pourquoi pas. Les testeurs sont vus comme dans un rôle intermédiaire peu passionnant car répétitif en 2 tâches : rédaction de tests et leurs exécutions. Pour faire fun et les caser en tant que développeur, l'automatisation des tests a été inventé. Il en faut, mais les tests fonctionnels requièrent un esprit critique qu'aucun automate ne peut avoir. De plus, il peut détecter des "trous de spèc" que ni le PO ni un développeur n'auraient pas pensé. Pour être mis en avant, il faut le faire participer à la démo avec l'équipe de son projet pour présenter quelques chiffres, le faire participer au Daily sprint comme un dév, qu'il mette aussi en avant le bon travail des développeurs (ce n'est pas un hater !). D'expérience aussi, le fait d'avoir ses tâches dans les US au milieu de celles des développeurs permet au PO d'avoir une preuve de son implication dans le projet, ce qui est valorisant. C'est un peu long mais "il faut chouchouter son testeur", il vous le rendra bien !

[@peewee3951]

@@ScrumLife PS : parmi les nombreux sujets que tu abordes dans ta chaîne, une seule vidéo (#26) sur les tests :(

[@r33iv44x]

7:03 Détecter et réagir très vite aux incidents de production a beaucoup de valeur, mais moins que de corriger les anomalies avant de livrer. Or tester, c’est avant tout chercher les anomalies.

[@mickaelarazor5260]

Le test exhaustif est impossible, et il n'y a pas que des anomalies. Anomalie signifie "en dehors de la norme". Si la norme (et donc les specs) est mal fichue, le produit ne conviendra peut être pas au client. Le testeur intervient aussi sur tous ces aspects non fonctionnels, mais pour ça, il faut souvent mettre le produit dans les mains d'utilisateurs tests pour avoir du feedback. Blinder les tests avant la mep, c'est très bien, mais pas toujours suffisant. Mettre en place du test AB sur la prod, ou une ouverture progressive par exemple, c'est très bien aussi. ☺️

[@lorenzodelpais6962]

Top video ! Comme d'habitude ! Je suis fan

[@ScrumLife]

Tu devrais rejoindre la communauté des VIP ! 😚 scrumlife.tv/community -- JP

[@adilbennani5780]

Super vidéo, merci

[@ScrumLife]

Avec grand plaisir ! Si tu devais résumer la vidéo en une phrase ou deux, quelle est la chose qui en ressort le plus pour toi ? -- JP

[@j0hnmerrick]

Excellente vidéo ! (Pouce vers le haut) Mais comment gérer les tests de non reg en agile? Sur un ancien projet entre les tests de non reg sur l’env puis sur la preprod du sprint -1, la rédaction des tests(step by step) on avait le temps de tester le sprint en cours que sur les 3 derniers jours de l’itération,d’où freeze code (et un burn down plat sur les 3/4 du sprint ...) La solution qu’on a mis en place c’est d’automatiser les tests...mais ça ne se fait pas du jour au lendemain hélas.

[@ScrumLife]

Pourquoi ne pas tester en continu au fil de l'eau ? On peut aller très loin en se basant sur de l'analyse de risque. Quelques pointeurs sur le sujet : - Un article de Jean-Pierre Lambert sur une équipe qui utilisait l'analyse de risque pour réussir à faire des releases en continu malgré l'absence de suffisamment de tests automatiques : jp-lambert.me/gestion-de-risque-formalisation-et-communication-1f86fb1eb0c1 - Captation d'un meetup avec Florian Zilliox qui parle de l'utilisation du test exploratoire pour gérer la non-régression à Meetic : kzbin.info/www/bejne/aYfVlIyrgsuKfcU Sinon bien entendu la meilleure option est d'automatiser la non-régression, mais ça vous y avez déjà pensé vous-même !

[@garfunk71]

Super intéressant, merci beaucoup pour cette vidéo ! Petit détail: la faute dans le titre qui risque de te pénaliser dans les recherches sur KZbin... Scum et Scrum c'est pas la même chose !

[@garfunk71]

Ici :) imgur.com/JZaBZsq

[@cog_g]

Arg. Je confirme je vois la faute :-(

[@thabetmabrouk2732]

Super ! juste une question: comment nous pouvons tester des systèmes embarqués critiques (Drone par exemple). Le de consister en HW + SW, le test en prod peut couter beaucoup, le dé d'un simulateur pour que le testeur teste couté des années de travails. le test de la partie HW est très difficile et il n'a aucune valeur business avant son intégration avec le software? Pas des instance Preprod, prod parce que les versions depend de HW. comment faire de du déploiement automatique? J'aime bien savoir votre opinion à propos sa.

[@sebastienpoulet-mathis3077]

Et pourquoi ne pas mettre en place plutot du TDD ? fr.wikipedia.org/wiki/Test_driven_development Les tests simplifient aussi la doc et le suivi du coup...

[@mickaelarazor5260]

Et pourquoi pas même du BDD? ☺️

[@krisrspk909]

Merci pour la vidéo, mais dans le cas d'un déploiement continu ?

[@ScrumLife]

Salut ! Peux-tu élaborer ta question s'il te plait ? Car spontanément je ne vois pas de conflit avec le déploiement continu -- on collabore et on se pose les questions en amont, on automatise, on suit ce qu'il se passe en prod... Merci d'avance pour tes compléments ! -- JP

[@krisrspk909]

Bonsoir Jp, je parlais du fait de tester une application qui est déployé plusieurs fois par jour ? L'automatisation est un bon moyen selon moi, de suivre la cadence

[@ScrumLife]

Oui, on automatise. Le testeur agile intervient alors surtout en amont (shift left) et en aval (shift right) plutôt qu'à mi-chemin entre le développement et la mise en production. -- JP

[@valeriebonnemains2865]

Très intéressante cette vidéo, l'idée du pair testing me plaît bien. Par contre je me pose une question, je comprends bien qu'on ne peut pas tout tester, mais quand on a une grosse appli, (même avec une équipe qui s'occupe du run et est prête à relever rapidement en cas de gros bug), j'ai du mal à me dire qu'on ne repasse pas dans toute l'appli pour checker qu'on n'a pas eu d'effet de bord. Où est ce qu'on doit se fier à l'équipe de dev qui doit nous dire les effets de bord probable pour tester uniquement ces parties ? Merci pour vos vidéos très instructive ;)

[@valeriebonnemains2865]

On travaille sur les tests automatique en effet, en attendant on va voir pour gérer les risques. Merci ;)

[@ViolaineT]

Super. G bc appris. Mais du coup entre le shift left, right ou le continous, c quoi la pratique la plus mâture agilement parlant?

[@ScrumLife]

Ces pratiques ne sont pas à opposer mais sont complémentaires. Le testeur Agile pratique les trois.

[@r33iv44x]

9:05 Le testeur tel qu’il est décrit ici va-t-il vraiment vérifier le résultat d’un changement de code à l’échelle d’une tâche (à l’intérieur d’une user story) et d’un commit avec le développeur ? De manière générale à cette échelle, les tests en boîte blanche ne sont-ils pas plus efficaces et pertinents ?

[@r33iv44x]

Je ne vois pas la contribution d’un testeur quand un développeur teste en boîte blanche. Quel rôle le testeur peut-il bien jouer quand un développeur joue avec les cycles micro-itératifs de TDD ?

[@r33iv44x]

J’imagine mal un testeur enseigner les principes SOLID, KISS, YAGNI, DRY ou SOC à un développeur. Un développeur qui pratique correctement TDD n’a pas besoin de chaperon pour s’assurer qu’il fait des tests ou que ses tests ont un sens.

[@luckypaddy]

Chez nous, il y a une équipe d'expert QA qui offre de l'accompagnement aux divers équipes dans le but de les monter en compétences. L'objectif est de créer des agents des essais qui agissent à titre de QA dans leur équipe. Nous restont en contact et effectuons des audits de leurs processus des essais. Nous travaillons étroitement avec des experts en agilité qui interviennent aussi dans ces équipes.

[@coachjimmycarroll]

Quel est ton opinion sur les équipes Scrum sans testeurs où les développeurs testent les fonctionnalités des autres développeurs ?

[@4sstylz]

Nous avons mis en place la « recette croisée » qui est un système que tu décrit ici. Concrètement, chez nous, il y a une interdiction absolue de merger son propre code. C’est l’un des principes d’Extreme Programming d’ailleurs : Puisque l’audit de code c’est bien, alors faisons le de manière systématique et en continu. - Le dev développe (si possible en mode test driving-developpement). - Il recette son propre code avec les TA pour ne pas faire perdre du temps à son collègue. - Un autre dev recette (nous n’avons pas de QA, seulement des devs et un PO dans certains cas). Il a un process lui décrivant le plan d’action technique, ce qui devait être fait coté métier, et un scénario de tests qui est au moins la preuve que ce qui est demandé fonctionnera. À ça il doit ajouter sa propre critique et faire des tests bien vicieux. En implantant ça on a fait un bon ÉNORME il y a quelques années. - Les devs s’approprient du code de leurs collègues. Plus de monde connait mieux le code en géneral. - Les devs évoluent et communique mieux techniquement. Au début, il y a beaucoup de travail à accomplir pour démolir l’égo de chacun mais en quelques semaines on a relevé le niveau de chacun. - La qualité de ce qui est produit s’est vraiment améliorée, de par du fait que les recetteurs se résponsabilisent et ne veulent plus laisser passer de bug. « C’est pas Jean qui a codé le bug, c’est Jean qui l’a codé mais… mince c’est moi qui a recetté : Quelle tanche je suis ». Biensur, ça ne dispense pas d’un Q/A. Mais pour moi, ex dev et actuellement PO c’est une pratique qui est fondamentale.

[@benoitgantaume]

Je l'ai rarement vu fonctionner. En général au premier coup de bourre ça se perd... Ca marche chez vous?

[@benoitgantaume]

Pour la revue de code par contre oui, ça marche bien. Je laisse libre de faire des revues à posteriori qui évitent de bloquer les mises en production.

[@4sstylz]

Ben ça marche à fond. Dans un coup de bourre ou tu a un incident qui te fou en stress tu a vite fait de faire la connerie du siècle donc justement ça a encore du sens dans ce cas d’avoir une relecture extérieur.

[@4sstylz]

Une revue de code après avoir fait la MEP c’est trop tard de mon avis. Concrètement pour voir si ça marche je te propose de faire un état des lieux de tes MR. Demande toi : - Si les audits que tu fait ont de la valeur ajouté alors que le dev / fix est déjà parti en prod. → Vous faite un état des lieux mais est-ce que ça fait vraiment bouger les choses ? - Si après des audits qui révèlent de la dette ou des problèmes alors il y a une vraie plan de correction qui se termine, systématiquement ou a quel fréquence ? Est-ce que ça corrige l’intégrale de l’audit ? - Si il y a plus ou moins de bug qui se produisent après des MEP avec l’un ou l’autre système ? Moi je peux répondre à ces mêmes questions. Avec mon XP, mon équipe. (J’avoue j’ai mon contexte à moi, ni ton/tes équipes et ni ton/tes produits). Dans notre cas les problèmes étaient éxtrèmes à l’époque : Chaque livraison causait des incidents, et on avait des sprints de maintenance en flux tendu stressant. Impossible de planifier, impossible de se concentrer. - Dans notre cas les audits après coup on a jamais eu le temps de les faire. On a bien traité des sujets genre problème de sécurité majeurs. Mais ça causait pleins de problème : C’est démotivant. C’est trop tard pour corriger les problèmes alors que le périmètre du produit a évolué depuis l’audit. C’est trop dur à planifier et il faut arbitrer entre du contenu métier, des features, et des taches (qui des fois étaient en nombre suffisant pour alimenter des sprints entiers) consacrés à résorber des défauts. - En cycle court, franchement c’est beaucoup plus tenable. Tu fait la recette croisée + audit croisé : Tu fait corriger le dev, il est deux fois plus qualitatif et même si ça te soule sur le coup c’est franchement mieux que se taper des jours / semaines de boulot à résorber ou même carrément à se prendre des incidents dû à un petit bout de code foireux. - La recette croisée c’est dans notre notion de finie et on s’y tient, donc audit systématique et on n’a presque pas à revenir sur une tache en soit. Ça ne pallie pas à tout : Il peux y avoir des problèmes d’architectures complexe sur le fond du code. Mais ça enlève pas mal de défauts mineurs trop bêtes qui sont corrigeable aisément sur le coup, avant d’avoir fait une MEP et ça fait monter en compétence l’équipe. - En mettant ça en place il y a deux ans on a vraiment beaucoup diminué le nombre de problème suite à une MEP…

[@tianadede349]

Mija, montre-toi