La Guilde ! - Devenez un expert en Quality Engineering

Jean-Francois Fresi

🎙 Le podcast des leaders de la qualité logicielle et du Quality Engineering
Chaque semaine, découvrez des techniques d'audit, de formation, d’automatisation des tests et de coaching pour optimiser votre qualité. La Guilde te guide à travers les défis de la transformation digitale avec "Shift Left", "Right", et "Up".
Pour responsables QA, ingénieurs qualité, CTO, tech leaders et passionnés.
✅ Méthodes actionnables
✅ Formats courts : 1 épisode/sem. et mini-série 10 min/jour.
Soutiens nous :
- Abonne-toi 🔔
- Laisse un avis et 5 étoiles (⭐️⭐️⭐️⭐️⭐️)
- Inscris-toi : https://laguilde.substack.com

Play

Open in

37 episodes
Avg 13 min
French

Episodes 37

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

Yesterday · 10 min
La qualité coute cher
La qualité, ça coûte cher.” Quand cette phrase vient de ton CTO, de ton VP Engineering ou de ton Head of Product, ta réponse habituelle (“oui mais...”) te fait perdre la discussion. Parce qu’il a raison, au moins à moitié. Et la moitié qui manque, c’est à toi de la porter. Dans cet épisode de La Guilde, je te donne une méthode en 4 étapes pour répondre à cette objection sans te justifier, même face au top management. C’est un arbitrage, pas une attaque, et ton rôle est de l’aider à décider sereinement. Au programme : Pourquoi répondre au top management est plus difficile qu’avec un collègue Étape 1 : accepter l’objection au lieu de te défendre Étape 2 : rendre visible le coût de la non-qualité, avec les données de ton entreprise Étape 3 : proposer des options plutôt qu’un simple budget Étape 4 : parler le langage de chacun (Head of Product, CTO, VP Engineering) Les 5 erreurs à éviter : brandir une norme, culpabiliser, te plaindre du budget, citer des chiffres non sourcés, dire non sans alternative Ta mission de la semaine : liste tes trois derniers incidents en production et estime ce qu’ils ont coûté (temps de correction, tickets, clients touchés, redéveloppement). Ce sera ta base pour la prochaine fois. Cet épisode s’adresse aux Test Leads, Test Managers, QA et à toute personne qui doit défendre la qualité face à un budget limité. La Guilde, le podcast des professionnels de la qualité logicielle.
October 25 · 11 min
Test premières semaines de Test Lead
Inscris-toi à ma masterclass : Tes 90 premiers jours comme Test Lead : quoi observer, décider et changer ? Tu es devenu Test Lead parce que tu étais un bon testeur. Et depuis, tu continues à faire le travail d’avant, avec un titre différent. Le problème, c’est que le rôle n’est plus le même. Dans cet épisode, on s’attaque à ce piège classique : la promotion qui ne s’accompagne d’aucune vraie transition. Résultat : un Test Lead qui exécute encore des tests, qui garde tout pour lui, et qui passe à côté de ce qu’on attend vraiment de lui. Au programme : Pourquoi on devient Test Lead par réflexe, sans que personne ne définisse le nouveau rôle Ce qui change concrètement : de “je fais” à “je fais faire, je cadre, je pilote” Les signaux qui montrent que tu es encore dans ton ancien poste Les premiers leviers pour faire la bascule, sans attendre qu’on te la demande Si tu es Test Lead, que tu viens de l’être, ou que tu manages des Test Leads, cet épisode va te donner un miroir et des pistes d’action. Un épisode de La Guilde.
October 23 · 8 min
5/5 - Faire vivre Playwright dans une équipe et progresser comme QA automaticien
Passer de la théorie à la pratique avec l'accompagnement Mission Playwright Comment faire vivre Playwright dans une équipe et progresser comme QA automaticien ? Matthieu Bridoux décrit ce qui rend un QA vraiment autonome et comment il forme un testeur manuel à l'automatisation. Dans cet épisode de la série "Playwright sur le terrain" : - Les 4 compétences d'un QA autonome : écrire un test lisible et robuste, structurer une suite qui grandit, diagnostiquer seul un test rouge en CI, travailler comme un développeur (branche, pull request, revue de code) - Pourquoi savoir défendre ses choix devant un développeur est le vrai marqueur d'autonomie - Former un testeur manuel : partir de ce qu'il sait déjà, puis locators, interactions, POM, fixtures, variabilisation des environnements - Intégration CI/CD, temps de retour, tri des échecs, responsabilités de maintenance À retenir : maîtriser Playwright, c'est aussi savoir intégrer les tests au quotidien de l'équipe et expliquer les choix faits. Pour qui ? Testeurs manuels en reconversion, QA qui passent à l'automatisation, Test Leads qui structurent la montée en compétences de leur équipe. Série : Playwright sur le terrain (épisode 5/5)
October 22 · 12 min
4/5 - Pourquoi les tests Playwright deviennent instables
Passer de la théorie à la pratique avec l'accompagnement Mission Playwright Pourquoi les tests Playwright deviennent-ils instables ? Matthieu Bridoux raconte un test flaky dont la cause n'était pas celle attendue et détaille sa méthode pour diagnostiquer un échec en CI. Dans cet épisode de la série "Playwright sur le terrain" : - Un cas réel : un test qui passe en local, échoue en CI, et la vraie cause (une fenêtre de consentement cookies) - Pourquoi augmenter le timeout ne règle presque jamais le problème - L'ordre d'enquête : historique des runs, trace Playwright, correction ciblée, validation par relances répétées - Les causes classiques de tests instables : synchronisation, données partagées, dépendances entre tests, environnement, appels réseau - Ce qu'une relance automatique (retries) peut masquer À retenir : la stabilité vient d'un diagnostic des causes, pas d'une tolérance accrue aux échecs. Pour qui ? QA, SDET, développeurs et équipes qui subissent des tests flaky et veulent restaurer la confiance dans leur pipeline CI/CD. Série : Playwright sur le terrain (épisode 4/5)
October 21 · 12 min
3/5 - Structurer une suite Playwright sans fabriquer une usine à gaz
Passer de la théorie à la pratique avec l'accompagnement Mission Playwright Comment structurer une suite Playwright sans fabriquer une usine à gaz ? Matthieu Bridoux explique quand extraire du code commun, quand le Page Object Model devient utile, et comment introduire Playwright dans un dépôt existant. Dans cet épisode de la série "Playwright sur le terrain" : - Organisation des fichiers et des dossiers d'une suite de tests - Fixtures Playwright : à quoi elles servent et quand les utiliser - Page Object Model : selon le contexte, pas par réflexe - Le seuil à partir duquel une abstraction devient utile - Indépendance des tests, gestion des données et des environnements - Les architectures qui compliquent la maintenance - Introduire Playwright dans un projet existant À retenir : la structure doit rendre les tests plus faciles à comprendre, à diagnostiquer et à modifier. Pour qui ? QA automaticiens, Test Leads, développeurs et équipes dont la suite de tests grossit et devient difficile à maintenir. Série : Playwright sur le terrain (épisode 3/5)
October 20 · 10 min
2/5 : Écrire un premier test Playwright qui résiste au changement
Passer de la théorie à la pratique avec l'accompagnement Mission Playwright Comment écrire un premier test Playwright qui résiste au changement ? Matthieu Bridoux partage sa grille de lecture d'une revue de code : locators, assertions, attentes et messages d'échec. Dans cet épisode de la série "Playwright sur le terrain" : - Ce qu'on regarde en premier dans la revue de code d'un QA débutant : le titre du test et sa dernière assertion - Sélecteurs Playwright : rôle et nom accessible (getByRole) d'abord, data-testid ensuite, CSS en dernier recours - Les erreurs d'attente les plus fréquentes, - Comment vérifier qu'un test contrôle vraiment le bon résultat - Assertions sur des valeurs métier plutôt que sur la simple présence d'un élément À retenir : un bon test dit clairement ce qu'il protège et pourquoi il échoue. Pour qui ? QA débutants et confirmés, testeurs manuels en reconversion vers l'automatisation, développeurs qui écrivent leurs tests Playwright.
October 18 · 11 min
1/5 : Quand faut-il automatiser avec Playwright ?
Passer de la théorie à la pratique avec l'accompagnement Mission Playwright Quand faut-il automatiser avec Playwright ? Matthieu Bridoux, expert en automatisation des tests, explique comment choisir le bon premier parcours à automatiser et dans quels cas il déconseille Playwright. Dans cet épisode de la série "Playwright sur le terrain" :- Pourquoi on n'automatise pas des tests, mais des parcours utilisateurs qui coûtent cher- Les 4 critères pour valider un premier parcours à automatiser (criticité métier, rejeu à chaque campagne, interface stable, données maîtrisées)- Les 2 pièges à éviter : commencer par la connexion seule, ou par le parcours le plus complexe- Comment gérer un prestataire externe instable : sandbox ou simulation- La complémentarité avec les tests manuels et exploratoires À retenir : le choix d'un test automatisé commence par un risque et un besoin de retour rapide, pas par l'envie d'utiliser un outil.Pour qui ? QA, testeurs, Test Managers, développeurs et équipes qui veulent lancer ou cadrer leur automatisation de tests end-to-end sans se tromper de priorité.Série : Playwright sur le terrain (épisode 1/5)
October 12 · 12 min
Automatisation des tests : quand s’arrêter ?
Automatisation des tests : jusqu'où aller sans exploser ton budget ni ta dette de test ?"On va tout automatiser." Six mois plus tard, la suite de tests est lente, des tests échouent sans raison et plus personne ne veut y toucher. Ce n'est pas de l'automatisation, c'est de la dette.Dans cet épisode, je te donne une méthode en 4 étapes pour décider quoi automatiser, jusqu'où aller et quand t'arrêter :1. Décider quoi automatiser, avec 4 critères : fréquence d'exécution, stabilité de la fonction, criticité métier et facilité de maintenance.2. Calculer le coût total d'un test, pas seulement son coût de création, pour savoir s'il est rentable.3. Fixer des garde-fous : plafonner la maintenance, corriger ou supprimer les tests instables, faire une revue régulière.4. Gérer ta dette de test : tests flaky, tests obsolètes, doublons, suite trop lente.Tu découvriras aussi les 5 erreurs à éviter, dont celle de viser un pourcentage d'automatisation, qui est un indicateur de vanité.GRILLE DE DÉCISION GRATUITEUne grille simple et basique, qui te donne déjà une tendance : automatiser, en discuter avec l'équipe, ou garder en manuel. À télécharger ici : https://tally.so/r/vG7geD
October 4 · 8 min
Comment être légitime face aux développeurs, PO et managers
« C'est bon, tous les tests sont passés. » Cinq minutes avant la mise en production, c'est la phrase qu'on attend de toi. Et personne ne te demande si c'est une bonne idée de livrer. Si on te perçoit comme celui qui exécute les tests, ce n'est pas un problème de compétence. C'est que tu parles d'activité, alors que les autres parlent de décisions. Dans cet épisode, je te donne 4 leviers concrets pour passer de « celui qui teste » à « celui qu'on consulte avant de décider » : → Rapporter des risques plutôt que des tests : un risque, un impact, une option → Adapter ton discours à chaque interlocuteur : développeur, Product Owner, manager → Défendre ta position sans t'effacer et sans jouer les gendarmes → Gérer un désaccord avec des faits et un objectif commun Tu repars avec des phrases prêtes à l'emploi pour ta prochaine réunion de go/no-go. À retenir : ton rôle n'est pas de dire non. Ton rôle, c'est que la décision soit prise en connaissance de cause. Et toi, dans quelle situation t'es-tu senti le moins légitime ? Dis-le-moi en commentaire, je lis toutes les réponses. Un épisode de La Guilde, la communauté des professionnels de la qualité logicielle.
September 27 · 8 min
Es-tu Test Lead sans le savoir ?
Tu fais peut-être déjà le travail d'un Test Lead (Lead QA) sans en avoir le titre. Dans cet épisode, je passe en revue 7 signaux concrets qui montrent que tu ne fais plus seulement du test logiciel, mais que tu pilotes déjà la qualité de ton équipe. Les développeurs, les PO et les autres QA viennent te consulter pour évaluer un risque, arbitrer une priorité ou comprendre l'impact d'une anomalie avant la mise en production ? Tu questionnes les critères d'acceptation, tu structures la stratégie de test, tu fais progresser les autres testeurs et tu influences les décisions sans autorité hiérarchique ? Alors tu exerces probablement déjà ce rôle. Le leadership qualité commence souvent avant le titre. Il commence au moment où tes décisions influent sur le travail des autres. Je termine sur le piège à éviter quand tu te reconnais dans ces signaux, et sur la question que tu dois absolument te poser pour faire évoluer ta carrière de testeur vers un rôle de Test Lead, QA Lead ou Test Manager. Autoévaluation gratuite de ta posture de Lead QA : https://tally.so/r/D4Qel5 Bootcamp Leader QA, 6 semaines pour prendre ton rôle de Test Lead avec une vraie méthode : https://shiftopsolutions.systeme.io/bootcamp-qalead Échanger avec moi sur ta situation : https://tally.so/r/QKdBNl Newsletter La Guilde : https://laguilde.substack.com Version vidéo sur YouTube : https://www.youtube.com/watch?v=UISQnooalDA Autoévaluation gratuite de ta posture de Lead QA : [lien] Bootcamp Leader QA, 6 semaines pour prendre ton rôle de Test Lead avec une vraie méthode : https://shiftopsolutions.systeme.io/bootcamp-qalead Échanger avec moi sur ta situation : https://tally.so/r/QKdBNl Newsletter La Guilde : https://laguilde.substack.com Version vidéo sur YouTube : https://www.youtube.com/watch?v=UISQnooalDA
September 20 · 10 min
Tester sans spécifications
Tu rejoins un sprint en cours. Le développeur te dit : "C'est prêt, tu peux tester." Tu demandes la spec. Il te répond : "Il y en a pas vraiment, on a fait au feeling, c'était urgent." Bienvenue dans la réalité de 80% des équipes agiles. Pas de user story formalisée, pas de critères d'acceptation, parfois même pas de maquette validée. Dans cet épisode, on parle de comment tester dans ces conditions, et pourquoi cette compétence peut rendre ton rôle plus stratégique que jamais. Au programme : 1️⃣ Pourquoi l'absence de spec n'est pas toujours un signe d'amateurisme, et ce que ça change dans ta posture 2️⃣ La méthode en 5 étapes : reconstituer l'intention, utiliser l'heuristique SFDIPOT, documenter en temps réel, tester par risque, clôturer par une déclaration de couverture 3️⃣ Les 5 pièges à éviter absolument, du "ça fonctionne donc c'est bon" au testing en solitaire Tester sans spec, ce n'est pas un sous-mode dégradé du testing. C'est une compétence de haut niveau, qui mobilise le sens critique, la pensée systémique et le leadership qualité. 👉 Tu veux muscler ce réflexe sur des cas concrets, avec un retour extérieur qui pointe ce que toi tu ne vois plus ? C'est exactement ce qu'on travaille dans le Bootcamp Leader QA, en mise en situation, pas en théorie. 👉 Infos et inscription : shiftopsolutions.systeme.io/bootcamp-qalead
September 18 · 17 min
5/5 - La performance pour les ops : observabilité, shift right et réalité terrain
La production révèle ce que les environnements de test ne montrent pas toujours. Dans ce dernier épisode de la série, on parle du rôle des ops dans la performance : supervision, observabilité, corrélation entre incidents et métriques, compréhension du comportement réel du système. On aborde aussi les notions clés : logs, métriques, traces, alerting, SLI/SLO, shift right. La performance ne s'arrête pas aux tests : elle se confirme et se comprend vraiment dans la réalité de production. Dernier épisode de la série "La performance : l'impact invisible" — la performance ne se pilote pas seulement avant la mise en prod, elle se surveille et se travaille dans la durée.
September 17 · 18 min
4/5 - La performance pour les développeurs : construire vite, mais construire juste
Attendre les tests de perf pour découvrir les problèmes, optimiser trop tard, ne regarder que le nominal : ce sont les erreurs les plus fréquentes côté dev. Et elles coûtent cher. Dans cet épisode, on montre que la performance se joue très tôt, dans les choix techniques et l'architecture : requêtes coûteuses, appels inutiles, traitements mal optimisés, dette technique silencieuse. Et on parle des bons réflexes à adopter : profiler, observer, challenger les hypothèses, penser scalabilité et résilience dès la conception. La performance ne se corrige pas uniquement après coup : elle se prépare dès les choix de conception et de développement.
September 16 · 18 min
3/5 - La performance pour les QA : un angle mort trop fréquent
La performance, un sujet réservé à quelques experts ? Pour les QA, ce temps-là est révolu. Dans cet épisode, on explique pourquoi la performance concerne directement les QA : elle impacte l'expérience utilisateur, elle révèle des fragilités invisibles en test fonctionnel, elle influence la qualité perçue. On parle aussi des réflexes à développer côté QA : intégrer la performance dans l'analyse de risque, penser temps de réponse et fluidité dès les scénarios, repérer les signaux faibles en recette. La performance n'est pas un sujet à côté de la QA : c'est une composante directe de la qualité.
September 15 · 16 min
2/5 - Le rôle du testeur de performance : au-delà des scripts et des courbes
Le cliché a la vie dure : le testeur de performance lance un outil, génère de la charge, produit un rapport. La réalité est bien plus large. Dans cet épisode, on parle du vrai rôle du testeur de performance : modéliser des usages réalistes, choisir les bons scénarios, interpréter les résultats, repérer les signaux faibles, et dialoguer avec les autres métiers. On passe aussi en revue les erreurs fréquentes : scénarios irréalistes, métriques mal lues, conclusions trop rapides, tests isolés du contexte métier. Le testeur de performance ne produit pas seulement des chiffres : il produit de la compréhension.
September 13 · 23 min
1/5 - Les tests de performance : ce qu'on mesure vraiment
"Ça ira en production." "On verra plus tard." "Si ça marche fonctionnellement, c'est suffisant." Trois phrases qu'on entend encore trop souvent, et qui montrent à quel point la performance reste un sujet mal compris. Dans ce premier épisode de la série "La performance : l'impact invisible", on pose le cadre : pourquoi tester la performance, ce n'est pas juste "mettre de la charge". On revient sur les grandes familles de tests (charge, stress, endurance, montée en charge, capacité) et sur ce qu'on cherche réellement à comprendre : temps de réponse, stabilité, tenue sous contrainte, comportements dégradés, limites du système. Tester la performance, c'est comprendre comment un système réagit sous contrainte, pas seulement vérifier qu'il tient.
September 6 · 11 min
Gérer les conflies entres les parties prenantes
Tu bloques une release parce qu'un risque te semble trop élevé. Le PO te répond que le planning est non négociable. Le dev t'explique que c'est un comportement attendu, pas un bug. Et tout le monde attend que tu trouves une solution. Vite. Dans cet épisode, on parle de la partie du métier de Test Lead qu'aucune formation technique ne prépare : le conflit. Et surtout, pourquoi il faut le gérer différemment selon qu'on est face à un dev ou face à un PM/PO. Au programme : 1️⃣ Avec les devs : pourquoi débattre de "c'est un bug ou pas" te fait perdre en crédibilité, et ce qui marche à la place 2️⃣ Avec les PMs et POs : comment traduire ton alerte technique en risque business pour être vraiment entendu 3️⃣ Que faire quand le désaccord persiste malgré une argumentation solide La règle qui traverse tout l'épisode : séparer la personne du problème. Un conflit bien géré n'est pas un conflit qui disparaît, c'est un conflit qui devient une décision claire, assumée et documentée. 👉 Tu te reconnais dans ces situations et elles te mettent encore en difficulté aujourd'hui ? Le Bootcamp Leader QA est fait pour ça : on travaille ces réflexes sur des mises en situation concrètes, pas en théorie, pour que le bon geste soit déjà là le jour où le vrai conflit arrive en réunion. 👉 Infos et inscription : shiftopsolutions.systeme.io/bootcamp-qalead
September 4 · 9 min
Défendre sa stratégie de test
Tu présentes ta stratégie en comité de pilotage. Et là : "Pourquoi vous ne testez pas ça ?" "On peut pas juste tester moins ?" Si tu bafouilles ou que tu sors une réponse trop technique, t'as déjà perdu. Pas parce que ta stratégie est mauvaise : parce qu'elle n'a pas été construite pour être défendue. Dans cet épisode, je te donne 3 leviers pour arrêter de subir ces réunions et commencer à les gagner : 1️⃣ Traduire en risques, pas en couverture 2️⃣ Anticiper les objections avant qu'on te les pose 3️⃣ Rendre ta stratégie lisible en 10 secondes Le piège du testeur, c'est de parler test à des gens qui pensent risque et argent. Cet épisode t'aide à sortir de ce piège. 👉 Tu veux aller plus loin et structurer une stratégie de test béton, capable de tenir face à n'importe quel comité ? Rejoins le Bootcamp Leader QA : shiftopsolutions.systeme.io/bootcamp-qalead 🎧 Bonne écoute, et dis-moi en commentaire ta dernière objection reçue en réunion sur une stratégie de test.
July 19 · 9 min
Accessibilité sans équipe dédiée
Pas de spécialiste a11y, pas de budget identifié, pas de process clair, juste une vague conscience collective que "ça serait bien d'y penser un jour." Dans cet épisode, on montre que l'accessibilité ne nécessite pas une équipe dédiée, mais une méthode, quelques réflexes bien placés, et une compréhension claire de pourquoi c'est devenu non-négociable. Au programme : → Pourquoi l'accessibilité n'est plus une option : le contexte réglementaire (Acte Européen d'Accessibilité, juin 2025) et l'argument business → Les bases : WCAG, RGAA, et les 4 principes d'un contenu accessible (perceptible, utilisable, compréhensible, robuste) → Comment l'intégrer sans expert dédié, rôle par rôle : design, développement, QA (les 3 niveaux de vérification), organisation → Les 4 erreurs qui font échouer les initiatives accessibilité : projet ponctuel, outils automatisés seuls, confondre conformité et accessibilité, attendre l'expert pour commencer Une chose à retenir : intégrer tôt, tester en continu, progresser par paliers. Pas besoin d'être conforme à 100 % du premier coup, chaque composant rendu accessible est un utilisateur de plus qui peut utiliser ce que tu livres. 🎙️ Un épisode de La Guilde, le podcast pour les passionnés de Quality Engineering.
July 12 · 10 min
Onboarding qualité : les 30 premiers jours dans une nouvelle équipe
Nouvelle équipe, nouveau produit, et trente jours pour comprendre comment les choses fonctionnent sans marcher sur les plates-bandes de quelqu'un ni promettre ce que tu ne pourras pas tenir. Dans cet épisode, on traverse semaine par semaine les trente premiers jours qui définissent ta crédibilité pour les mois qui suivent. Au programme : → Semaine 1 : pourquoi écouter avant tout, les trois questions à poser à chaque membre de l'équipe, et l'intérêt d'explorer le produit avec un œil neuf → Semaines 2-3 : cartographier les risques, analyser la stratégie de test existante, repérer les quick wins → Semaine 4 : produire un bilan partageable, lancer un premier chantier concret, formaliser son périmètre → Les 4 erreurs classiques qui compromettent l'onboarding qualité : arriver avec ses solutions, rester dans son couloir, promettre trop tôt, ignorer le rythme de l'équipe Une chose à retenir : écouter, cartographier, agir progressivement. La crédibilité en qualité se gagne dans la durée, et elle commence par un premier mois bien géré. 🎙️ Un épisode de La Guilde, le podcast pour les passionnés de Quality Engineering. 📌 Un cadre structuré pour accompagner ta prise de poste QA, Test Lead ou Test Manager ? Retrouve le pack coaching prise de poste de La Guilde en description.

Showing 1–20 of 37 episodes