Un test manager agile ou un QA lead SAFe n'a plus de phase de recette à piloter en fin de projet. Les testeurs sont dans les équipes, les tests automatisés tournent dans le pipeline et le train intègre son travail au fil du PI. Le poste consiste à écrire une stratégie de test commune à plusieurs équipes, à faire respecter une Definition of Done qui inclut les tests et à organiser l'intégration de bout en bout avec la system team. Les missions françaises ajoutent souvent le web et le mobile, et la responsabilité des recommandations go ou no-go.
Prudence face aux CV qui recyclent un parcours de responsable recette en cycle en V avec le vocabulaire SAFe. Le signal se trouve dans les exemples : une pyramide de tests corrigée, une quarantaine des tests instables, un test de contrat entre deux équipes, une Definition of Done changée et ses effets.
La certification ISTQB Agile Test Leadership at Scale (CT-ATLaS) cible ce rôle, mais l'ISTQB la retire le 1er janvier 2027. Les certificats déjà obtenus restent valables et complètent ces exemples sans les remplacer. Le PDF propose un cas de 20 minutes sur un train qui livre une fois par PI avec deux semaines de recette manuelle.
Pratiques et outils d'un QA lead dans un train SAFe
Built-in Quality (SAFe)
Le principe SAFe selon lequel la qualité se construit pendant le travail au lieu d'être contrôlée après. Il pousse les tests vers le début du cycle (shift-left). Pour le test manager, cela se traduit par des critères d'acceptation testables, des tests écrits avec la story et une Definition of Done tenue.
Definition of Done
La liste des conditions pour qu'une story ou une feature soit terminée. Le test manager y fait entrer les tests automatisés, les critères non fonctionnels et le traitement des anomalies. Une DoD sans tests recrée une recette décalée d'un sprint.
Quadrants et pyramide des tests
Les quadrants des tests agiles classent les tests selon qu'ils guident le développement ou critiquent le produit, côté technique ou côté métier. La pyramide indique la répartition visée : beaucoup de tests unitaires, moins de tests d'API, peu de tests d'interface. Les deux servent à repérer ce qui manque dans une équipe.
BDD et Gherkin
Le Behavior-Driven Development part d'exemples écrits avec le métier, au format Given / When / Then, puis les automatise avec Cucumber ou un équivalent. Bien utilisé, il sert de documentation vivante. Mal utilisé, il produit des centaines d'étapes d'interface que personne ne relit.
System team et system demo
La system team construit le pipeline et les environnements du train, et aide aux tests de bout en bout. La system demo montre le système intégré, avec un parcours complet. Le test manager vérifie qu'elle repose sur des tests réels du parcours complet.
Tests de contrat (Pact, OpenAPI)
Ils vérifient que deux composants qui s'appellent respectent le même contrat, sans attendre un environnement commun. Pact fait écrire les attentes par le consommateur et les vérifie chez le fournisseur. Ils évitent de découvrir les ruptures d'interface en fin de PI.
Pipeline CI/CD et gestion des tests
GitLab CI, Jenkins, GitHub Actions ou Azure DevOps lancent les tests à chaque changement. Les résultats remontent dans un outil comme Xray ou Squash TM pour la traçabilité. Le test manager fixe quels tests bloquent quelle étape et le temps cible de chacune.
ISTQB CT-ATLaS
Agile Test Leadership at Scale, certification ISTQB au syllabus 2.0 : 40 questions en 120 minutes, après la Foundation. L'ISTQB la retire le 1er janvier 2027, avec des derniers examens jusqu'au 31 décembre 2026. Les certificats obtenus restent valables. Elle couvre l'assistance qualité et les processus de test dans une organisation agile à l'échelle.
L'intitulé varie : test manager SAFe, QA lead, responsable qualité d'un train, parfois coach qualité. Le périmètre aussi. Certains postes encadrent une équipe de testeurs et d'automaticiens répartis dans les équipes, d'autres sont un rôle de référent sans équipe en propre. Dans les deux cas, le test manager agile travaille avec le RTE, la system team, les product owners et les architectes, et doit obtenir des équipes qu'elles appliquent des règles qu'il ne contrôle pas directement. Les questions portent sur ce que la personne a fait changer dans les pratiques de test d'un train, mesures à l'appui.
Les compétences d'un test manager agile à contrôler
- Stratégie de test commune à plusieurs équipes
- Shift-left et Definition of Done
- Intégration et tests de bout en bout du train
- Gouvernance de l'automatisation
- Exigences non fonctionnelles dans le backlog
- Indicateurs qualité et décision de release
Cinq situations d'entretien pour un test manager agile
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · senior
Le train compte huit équipes et aucune phase de recette finale. Que contient votre stratégie de test, et qu'est-ce qui reste à la main des équipes ?
Une bonne réponseUn document court commun au train : niveaux de test et qui les porte (équipe, intégration du train, solution), répartition visée entre tests unitaires, d'API et d'interface, règles de la Definition of Done, environnements, données de test, tests non fonctionnels et critères de mise en production. Les équipes choisissent leurs techniques et leurs cas. Le test manager fixe le cadre, les standards d'outillage et ce qui se mesure, puis vérifie qu'il est appliqué.
Signal d'alerteUn plan de test de 60 pages en cycle en V recopié, ou au contraire « chaque équipe fait comme elle veut », sans rien de commun au niveau du train.
Question 2 · confirmé
Une équipe déclare ses user stories terminées alors que les tests passent au sprint suivant. Que changez-vous ?
Une bonne réponseLa Definition of Done de l'équipe : une story est terminée quand ses critères d'acceptation sont testés, ses tests automatisés écrits et passés dans le pipeline, et les anomalies trouvées corrigées ou acceptées par le product owner. Le testeur participe à l'affinage pour que les critères soient testables avant le sprint. On suit les stories rouvertes pour mesurer l'effet.
Signal d'alerteAccepter un sprint de test décalé, qui recrée une mini-phase de recette, ou demander aux testeurs de travailler plus vite.
Question 3 · senior
En fin d'itération, chaque équipe montre ses écrans, mais personne n'a testé le parcours complet sur l'environnement commun. Comment organisez-vous les tests d'intégration du train ?
Une bonne réponseUne intégration continue des composants de toutes les équipes sur un environnement commun, avec une suite de bout en bout courte lancée à chaque intégration et pas seulement en fin d'itération. La system team ou une équipe désignée tient l'environnement et la suite. La system demo se fait sur cet environnement, sur un parcours complet. Les échecs d'intégration sont traités comme des anomalies de premier rang.
Signal d'alerteUne semaine de tests d'intégration en fin de PI, qui reconstitue une recette en cycle en V.
Question 4 · confirmé
La suite de bout en bout du train échoue une fois sur trois sans changement de code. Comment traitez-vous les tests instables ?
Une bonne réponseMesurer le taux d'échec par test, mettre en quarantaine les tests instables hors du chemin bloquant, avec un responsable et un délai de correction, et chercher les causes : attente fixe, données partagées, dépendance externe, ordre d'exécution. Un test en quarantaine trop longtemps est réécrit ou supprimé.
Signal d'alerteRelancer jusqu'à ce que ça passe, ce qui apprend aux équipes à ignorer le rouge.
Question 5 · senior
La direction veut un taux de couverture de tests unique pour tout le train. Que proposez-vous à la place ou en complément ?
Une bonne réponsePeu d'indicateurs reliés à une décision : anomalies trouvées après la mise en production et leur gravité, taux d'échec des changements en production, délai de correction, part des stories livrées avec leurs tests automatisés, durée et stabilité du pipeline. La couverture de code se lit par composant, avec la couverture des parcours critiques. Chaque indicateur a un usage écrit.
Signal d'alerteFixer un objectif de 80 % de couverture de code pour tous, ce que les équipes atteignent avec des tests sans assertion.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Test manager agile et QA lead SAFe : questions fréquentes
Faut-il encore un test manager quand les équipes sont agiles ?
Oui dès que plusieurs équipes livrent un même produit. Chaque équipe teste ses stories, mais personne ne porte spontanément les tests de bout en bout, les règles d'automatisation communes, les tests non fonctionnels ou la lecture des anomalies échappées. Le rôle change : moins d'exécution et de planification de campagne, plus de cadre, d'outillage et d'accompagnement des équipes. Certaines organisations l'appellent QA lead ou coach qualité.
Quel test technique pour un QA lead SAFe ?
Une revue de stratégie en entretien. À partir de la description d'un train fictif (équipes, pipeline, répartition des tests, anomalies échappées du dernier PI), la personne dit ce qu'elle change en premier et comment elle le mesure. Une suite de bout en bout instable à diagnostiquer s'y ajoute. Vingt minutes suffisent pour voir si elle raisonne en règles communes ou en campagne de recette.
Un test manager agile doit-il savoir coder ?
Il doit lire un test automatisé, comprendre un pipeline et discuter d'un framework avec les développeurs. Écrire lui-même la suite complète n'est pas attendu, sauf si le poste combine QA lead et automaticien principal. Un candidat qui ne sait pas dire pourquoi un test d'interface est instable, ou où placer un test de contrat, aura du mal à faire évoluer les pratiques d'un train.
SAFe est-il un prérequis, ou un autre cadre à l'échelle suffit-il ?
Les problèmes de test sont proches dans SAFe, LeSS ou une organisation maison à plusieurs squads : intégration entre équipes, dépendances, automatisation commune. SAFe ajoute son vocabulaire (PI, system demo, system team, enablers) et son rythme. Une personne venue d'un autre cadre s'y adapte si elle a déjà tenu une stratégie de test pour plusieurs équipes. Cette expérience compte plus que le nom du cadre.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
