Le QA ne s'arrête pas à la fin du sprint. Ni au périmètre du projet.

Pour clore cette série, Christophe Popiol et moi on élargit la focale : le rôle des communautés QA comme France-QA dans la montée en compétences collective, ce que les entreprises recherchent vraiment quand elles recrutent un QA (spoiler : pas juste quelqu'un qui exécute des cas de test), et comment se différencier concrètement pour trouver des missions qui ont du sens.

Curiosité, autonomie, posture d'explorateur : c'est ça que le marché valorise. Et c'est ça que cette série a cherché à illustrer, épisode après épisode.

Sur desktop, les specs sont incomplètes. Sur mobile, elles sont insuffisantes par construction.

Devices, OS, réseau instable, interruptions, gestes, contextes d'usage réels : le mobile expose tout ce que les cas nominaux ne couvrent jamais. Et c'est là que les QA qui se limitent aux specs se font rattraper par la réalité utilisateur.

Dans cet épisode, Christophe Popiol partage sa vision du QA mobile comme explorateur — celui qui teste dans la vraie vie, observe les usages réels, et ne se contente pas de valider que ça "fonctionne en conditions idéales".

On parle batterie, performance, interruptions, et posture d'investigation dans un contexte où l'environnement est par nature incontrôlable.

Si tu testes uniquement ce que tu vois à l'écran, tu testes la surface.Les vraies anomalies, elles se cachent ailleurs : dans les logs, dans les temps de réponse, dans les warnings que personne ne regarde.

Dans cet épisode, Christophe Popiol explique comment un QA mature sort du mode "boîte noire" pour exploiter les signaux techniques. Erreurs silencieuses, comportements intermittents, dégradations de performance : autant d'indices que l'UI ne te montrera jamais mais que les logs, eux, racontent.

On parle méthode : comment corréler symptômes et causes, comment poser les bonnes questions au bon niveau, comment passer du cochage de cases à l'enquête système.

"Je suis QA fonctionnel. Le code, c'est pas mon problème."

C'est la réponse confortable. Ce n'est pas la bonne.

Dans cet épisode, Christophe Popiol et moi on s'attaque à la question qui fâche : est-ce qu'un QA qui ne regarde jamais le code peut vraiment bien tester ?

On ne parle pas de devenir développeur. On parle de lire un diff, comprendre une stacktrace, identifier les zones à risque avant même d'ouvrir l'appli.

Comprendre le code, c'est comprendre ce qu'on teste. Et ça change tout : sur la couverture, sur les échanges avec les devs, sur l'anticipation des effets de bord.

Tu testes ce qui est écrit. Tu couvres le périmètre. Tu fermes tes tickets.Et pourtant… des bugs passent. Des angles morts persistent. Des décisions implicites ne sont jamais questionnées.

Dans ce premier épisode, j'accueille Christophe Popiol , professionnel QA engagé dans la communauté , pour ouvrir une série qui va déranger quelques habitudes.

On démonte ensemble le mythe du QA "exécutant de cas de test" : pourquoi les specs sont toujours incomplètes par nature, ce que ça coûte de s'y limiter, et ce que le vrai rôle du QA implique vraiment : questionner, explorer, détecter les signaux faibles.

Tu viens d'être nommé Test Lead. Ou tu l'es depuis quelques mois et tu as encore ce sentiment bizarre d'être entre deux chaises. Ni vraiment testeur, ni vraiment manager.

C'est normal. Et c'est exactement le sujet de cet épisode.

La prise de poste Test Lead est l'une des transitions les plus mal accompagnées de nos métiers. On prend le meilleur profil de l'équipe, on lui donne un titre — et on s'attend à ce que ça suive. Mais les compétences qui t'ont amené là ne sont pas celles dont tu as besoin maintenant.

Dans cet épisode, on démonte les 4 erreurs classiques du Test Lead débutant :→ Rester testeur dans la tête alors que le rôle a changé→ Vouloir tout contrôler au lieu de structurer et déléguer→ Oublier de communiquer vers le haut — et subir en silence→ Confondre couverture de tests et vraie qualité

Et surtout, on parle de ce qu'on fait à la place : comprendre avant d'agir, poser des critères clairs, devenir visible côté produit, et construire les bonnes relations — avec ton équipe QA, les devs, et le PM.

En résumé : comprendre, structurer, influencer. Le titre ne fait pas le rôle. C'est la posture qui le construit.

🎙️ La Guilde — le podcast des professionnels du Quality Engineering📬 Newsletter & ressources : laguilde.substack.com

Deux critères vagues dans la user story. Un sprint qui part mal. Un dev qui dit "c'est fini", un QA qui trouve des bugs, un PO qui dit "c'était pas ça". Le scénario te parle ?

Dans cet épisode, on ouvre le vrai chantier : les critères d'acceptance. Ce contrat interne qu'on bâcle faute de temps et qui coûte deux à trois fois plus en retravail qu'il n'aurait coûté à bien écrire.

Au programme :→ Pourquoi l'ambiguïté a un coût direct sur la vélocité→ Les 4 dimensions d'un bon critère (nominal, alternatif, erreur, non-fonctionnel)→ Given/When/Then vs liste de règles : quand utiliser quoi→ Two rituels concrets pour changer la pratique en équipe : Three Amigos et Definition of Ready

Pas de théorie décorative. Des formats actionnables, des exemples concrets, et une règle simple : si tu ne peux pas le vérifier de façon non ambiguë, il n'est pas encore assez précis.

🎙️ La Guilde, le podcast des professionnels du Quality Engineering📬 Newsletter & ressources : laguilde.substack.com

Ta suite de régression prend 3 jours à tourner et personne n'ose rien supprimer ?

Dans cet épisode, je démonte le mythe du "il faut tout tester" et on pose une approche concrète pour reprendre le contrôle : auditer sa suite existante, prioriser par le risque, et segmenter par fréquence d'exécution.

👉 Résultat : moins de bruit, plus de confiance, un feedback loop qui a du sens.

Au programme :

• Pourquoi les suites de régression dérivent (et coûtent cher)
• Le principe du test basé sur le risque appliqué à la régression
• 3 actions concrètes pour restructurer ta suite dès ce sprint

Pas de théorie décorative. Du terrain, des choix, de l'ownership.