Test Agile (Scrum) : quelle forme a votre stratégie de test ?

[@ScrumLife]

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

[@vinsoc9776]

Très bonne vidéo et forte intéressante pour comprendre la mise en place d une stratégie de test. Pour ma part j ajoute la dimension MVP comme jalon supplémentaires afin d avoir des tests un peu plus poussés sur les composants essentiels du projet. Merci pour votre taff 😊

[@ScrumLife]

Merci pour le complément et le compliment ! Que quel(s) type(s) de projets et produits interviens-tu ? -- JP

[@informatiquepixels8327]

Merci

[@ScrumLife]

Mais de Rien ! Robin

[@ScrumLife]

Salut @informatiquepixels8327 ! Merci à toi d'avoir regardé la vidéo, ça me fait super plaisir que tu sois passé par là ! 😊 Est-ce qu'il y a quelque chose en particulier qui t'a marqué ou une question que tu te poses sur les événements Scrum ou les approches agiles ? J'adore échanger avec la communauté, alors n'hésite pas à partager tes réflexions ou tes expériences ! À bientôt, Robin🧡 #ScrumLife

[@NicolasRemyDahu]

Quand on arrive sur du vieux code legacy, la forme de la stratégie de tests c'est plutôt le pole dance :D

[@curious-academy]

Je rejoins ce qui a été dit; Ici, on a aucune notion d'agilité. En soi, on est sur du tradi mis à la sauce "Je vulgarise". Du coup, je pense qu'il manque dans cette vidéo de commun tu intègres une vraie stratégie de tests, au niveau d'un user story, de comment tu l'impact dans ton delivery et comment tu le fais correspondre avec tes tests d'acceptation. et puis, en effet, quid d'un projet legacy, ici, on a plus du tout les meme stratégies. enfin, si certaines, mais pas toutes. et puis un e2e bien fait peut s'inspirer des autres tests et aussi, comment aider par exemple des recetteurs qui intègrent un projet agile ? des tests à la Spec Flow par exemple aident à la lisibilité, donc à l'autonomie et à la communication etc ... il y a encore beaucoup à dire quid pour réussir à automatiser, comme certains l'ont amené aussi quid pour arriver à une excellence technique, quand ... ton équipe est jeune et s'éparpille sur les effets de mode

[@CarlFrenee]

Très intéressant, mais quels outils prendre selon les types de test ? Par exemple, un test de comportement, on le fais de la même façon qu'un test unitaire ?

[@ScrumLife]

Bonne question, la réponse est "plutôt non" : Différents outils et différentes manière de faire existent pour chacun des types de tests. Serais-tu intéressé par un live sur le sujet ? Robin

[@Agilitest]

Nice job !

[@sebastienlichtenauer6500]

Concernant les vidéos de formation "Testeur Agile" en partenariat avec artisan développeur, j'ai deux questions. Tout d'abord, est-ce bien toi qui anime, que l'on voit sur les vidéos ? Ensuite le prix comprend toutes les vidéos et surtout pour combien de temps le visionnage est-vil valide ? Merci pour ton retour

[@ScrumLife]

Oui c'est bien moi qui anime. Nous faisons ensemble l'introduction et la conclusion pour plus de relief mais la formation elle-même est animée par moi-même. Le prix comprend toutes les vidéos du module ; il n'y a qu'un seul module Testeur Agile et cela représente 1h30 de contenu. Il n'y a pas de limite de temps du visionnage. -- JP

[@MichelHubert-ff8kq]

Il a un meilleur mot dans.ton Développement (fonctionnement au lieu de ca marche)

[@ScrumLife]

Salut @MichelHubert-ff8kq ! 😊 Merci pour ton commentaire et ta suggestion intéressante 👍. Le choix des mots est super important, c'est vrai ! "Fonctionnement" apporte une précision différente et peut effectivement enrichir notre vocabulaire. C'est génial de voir notre communauté s'investir autant. 💡 D'ailleurs, que penses-tu de l'impact du choix des mots en général dans un cadre agile ? As-tu d'autres conseils ou termes que tu aimerais que l'on utilise plus souvent ? Hâte d'échanger davantage avec toi ! À bientôt, Robin 🚀

[@arey-gnuk]

La vidéo est intéressante, cependant, comme dit plus bas, je pense qu'il ne fallait pas associer "agile" à "tests" ou alors parler de TDD et d'intégration continue (cf Extreme programming) mais ça aurait pu être l'objectif d'une autre vidéo. Je ne suis pas d'accord avec le coverage comme un but tel que tu le suggères parce que pour moi le coverage est un outil pour mesurer si j'ai pas surconceptualisé mon implémentation lorsque je fais du TDD. Du coup j'aurais plus insisté sur le côté pertinent. Pour ma part, un test unitaire test une unité fonctionnelle, je vois juste les différents granularités de tests en fonction du feedback. Ainsi chaque test est rédigé d'une manière à avoir un but en terme de règle métier plutôt qu'une règle technique, ce qui aide à désigner. Bref, je m'étale un peu, j'ai vu que tu collabore avec des crafters, c'est cool, je suis allé au DDD Europe il y a plus d'une semaine, il y avait de très bons talks en plus de celui de Kent Beck, je t'invite à y jeter un coup d'œil, ça pourrait te donner des idées ;) Bonne journée !

[@ScrumLife]

Merci pour les pointeurs !

[@OlivierFarlotti]

Est-ce que l'impact de la non qualité d'une fonctionnalité ne pondère pas le coût ?

[@ScrumLife]

Oui, en effet. Tout comme on ne prendra pas les mêmes décisions selon la criticité du produit (divertissement vs. financier vs. médical/militaire/centrale nucléaire).

[@mickaelarazor5260]

Bonne vidéo pour un public non averti. Avec toutefois des petites imprécisions. - Le test de comportement de bout en bout existe (un alpha test où on couvrirai l'ensemble des domaines fonctionnels en serait un). - Dans la stratégie, on oublie pas non plus les tests d'acceptation utilisateur et certains tests "Non fonctionnels" qu'on ne peut pas toujours automatiser. - Comme vous le dites également, l'explication sur le test fonctionnel est incorrect. Un test unitaire peut être fonctionnel ou structurel. Le "test fonctionnel" n'est pas un niveau de test.

[@rollandwinneruruna]

J'entends aussi parler des tets de non régression. Mais après avoir visionné cette video, ben ça existe pas. Que dis tu?

[@arey-gnuk]

Tout test automatisé ou même manuel est un test de non régression, si ton test ne joue pas un rôle sur une possible régression, c'est qu'il n'est pas pertinent, autrement dit qu'il ne test rien. Souvent ce qu'on appelle test de régression est en fait la campagne de tests manuels qu'on retrouve dans un métier de testeur. Pour moi cette classification n'a plus de sens à partir du moment où vous faites d'autres stratégies de tests que les tests manuels.

[@ScrumLife]

Effectivement nous n'avons pas mentionné ce terme. On pourrait faire une petite vidéo pour poser test de non-régression et test d'acceptation. Dans la pyramide de test de la vidéo on parle bien essentiellement voire exclusivement de tests de non-régression.

[@mickaelarazor5260]

@@ScrumLife Attention, on parle officiellement de "test de régression" et pas de "non régression" qui est un abus de language. Si j'écris un test, c'est pour qu'il trouve une régression. Mais du fait le la complexité combinatoire, aucun test ne peut prouver qu'il n'existe pas de régression dans un système complexe. Le "Test de non régression" est une chimère. Le test de régression en revanche est bien défini par le cftl.

[@mickaelarazor5260]

Un test de n'importe quel niveau qui est rejoué dans le but de trouver des régressions sur le produit est un "test de régression". Ça inclut tout type de test dont le test unitaire, le test de version, le test de performance et autres... 😉

[@tianadede349]

Mija, où-es tu ?

[@laulefly]

ok pour la stratégie de tests, mais je ne vois pas en quoi elle est agile !!!! dans cette présentation, elle est juste .... très traditionnelle !! quid des automates de tests avec les NOK auto qui sécurisent la chaine ? non, vraiment rien d'agile dans cette pres à mon sens .....

[@ScrumLife]

Aïe ! En effet, c'était une telle évidence que nous avons oublié de préciser que les différents tests de la pyramide étaient essentiellement si ce n'est intégralement automatisés. Quant au "agile" ou pas, c'est un comme le rôle de "testeur agile" : on parle plutôt du test et testeur moderne, mais ce sont les noms qui se sont répandus.

[@lemaitrejean4639]

@@ScrumLife Commnt etre agile en integrant les test automatise dans un backlog sans testeur. Une equipe de dev qui creer regulierement des test automatises de plus en plus complexes en utilisant scenarios deja valider par le PO pour reduire la non regression des prochain deployement.

[@mickaelarazor5260]

@@lemaitrejean4639 Complètement, mais pas uniquement. Il faudra aussi que l'équipe mette en place des process de tests d'acceptation utilisateurs et opérationnels, et soit à l'aise avec les notions gestion du risque, d'effort de test et de couverture pour lesquels un testeur "pro" est formé. Il y aussi un risque de perdre la notion d'indépendance du test: on est pas toujours objectif quand on teste ses propres productions. Mais tu as raison, dans une équipe mature auto organisée, ça peut fonctionner. Dans tous les cas, le QA peut adopter un rôle de coach (comme le scrum master qui n'est pas un chef de projet), et se rendre de moins en moins indispensable.

[@majucamex08]

A lot of bloff it is just repetition of what we could find and argue on literature