L4 / IC3 · 2 à 5 ans
Préparation entretien QA Engineer, ce qui vous attend
Si vous préparez un entretien QA ou SDET (en France l'intitulé varie : QA Engineer, ingénieur test automatisation, testeur automaticien), le principal changement à anticiper, c'est que la barre s'est déplacée vers le code. La plupart des process QA mid-level incluent désormais un round de coding juste en dessous de la barre SWE, et le round d'automatisation suppose que vous avez déjà construit et maintenu une vraie suite, traqué les tests flaky et défendu ce qui mérite de tourner en CI.
Un process typique : pré-screen recruteur, un coding screen, un round de test design (énumérer les cas de test d'une feature, puis défendre ce que vous automatisez), un round pratique d'automatisation ou de test d'API, puis un comportemental avec le hiring manager. Les grands groupes tech recrutent ce poste sous les titres SDET ou SETI et puisent dans le pool de questions SWE ; les boîtes plus petites compressent en 3 ou 4 rounds plus pratiques. En France, la certification ISTQB rassure les ESN et les grands comptes, mais elle ne remplace jamais le round de coding.
La barre IC3, c'est porter la qualité d'un périmètre produit : la suite d'automatisation, les quality gates de la CI, le go / no-go de release, et le taux d'échappées sur lequel l'équipe est jugée.
Version personnalisée
Ce guide couvre la barre générale pour QA. Collez votre offre et Calibrd la rend personnelle : ce que cette entreprise précise demande, où votre CV est léger, et une simulation complète que vous répétez à voix haute jusqu'à être prêt(e). Tout se passe dans votre navigateur, rien à installer. Calibrd repère votre niveau à partir de votre CV, du stage au poste de direction. Gratuit pour commencer.
Mise à jour 2026
Ce guide couvre la barre générale pour QA. Quelques choses ont changé en France en 2026, l'AI Act encadre le recrutement IA à partir du 2 août, 31 % des candidats utilisent déjà l'IA pour préparer (APEC), les mises en situation remplacent les tests classiques, et le cycle de recrutement reste à 12 semaines. Lire ce qui a changé en 2026 →
Ce qui sera attendu de vous
- Porter la stratégie de test d'un périmètre produit : ce qui est couvert en unitaire, en intégration et en end-to-end, et ce qui reste manuel
- Construire et maintenir la suite automatisée (Playwright, Cypress ou Selenium, plus des tests d'API) et la garder assez rapide pour que les devs lui fassent confiance
- Mettre en quarantaine et analyser les tests flaky pour qu'une CI rouge veuille dire quelque chose
- Mener du test exploratoire orienté risque sur les nouvelles features et apporter des données au go / no-go
- Pousser la testabilité dans le code avec les devs : points d'accroche de test, environnements seedés, données de test réalistes
- Suivre les chiffres sur lesquels la qualité est jugée : taux d'échappées, taux de flakiness, temps de feedback
Process d'entretien typique
La plupart des entreprises suivent une trame similaire pour les entretiens QA. Délai calendaire total : 3 à 5 semaines du pré-screen recruteur jusqu'à l'offre.
Questions types à anticiper
Représentatives de ce que les entreprises demandent à ce niveau, pas une liste exhaustive. Lancez le scan gratuit ci-dessus pour des questions prédites liées à une offre d'emploi précise. L'extension Chrome ajoute l'entraînement vocal avec coaching IA sur chaque réponse (technique, design système, comportemental, motivation).
- “Un test échoue une fois sur dix et passe au retry. Déroulez comment vous trouvez la cause, et ce que vous faites du test tant qu'il est flaky.”
- “Écrivez les cas de test d'un sélecteur de dates utilisé pour réserver des vols. Lesquels vous automatisez, lesquels restent manuels, et pourquoi ?”
- “Votre suite UI compte 4 000 tests et tourne en trois heures. Ramenez le feedback sous 15 minutes sans supprimer de couverture. Qu'est-ce qui va où ?”
- “Designez le framework d'automatisation d'une web app où 40 devs livrent tous les jours. Couvrez la répartition en pyramide, les environnements, les données de test et le reporting.”
- “Designez les quality gates d'une pipeline qui déploie 20 fois par jour. Qu'est-ce qui tourne à chaque commit, qu'est-ce qui tourne la nuit, et qu'est-ce qui bloque vraiment un déploiement ?”
- “Designez le plan de test de charge d'un tunnel de paiement e-commerce avant des soldes. Que mesurez-vous, et quel chiffre dit qu'on ne lance pas ?”
- “Parlez-moi du pire bug passé en production sous votre responsabilité. Comment a-t-il traversé les tests, et qu'est-ce qui a changé ensuite ?”
- “Décrivez une fois où vous avez défendu le blocage d'une release. Quelles preuves avez-vous apportées, et comment ça s'est terminé ?”
- “Parlez-moi d'un bug report qu'un dev a contesté. Comment avez-vous fait valoir votre analyse ?”
Benchmark de salaire
Salaire médian pour QA dans les grandes boîtes tech US, chiffres principaux en USD. Paris / Berlin / Singapour paient typiquement 30 à 50 % de moins en base ; les ratios d'equity varient selon le stade de l'entreprise.
Les filières SDET / SETI des grands groupes (Google, Amazon, Microsoft) paient proche de la grille SWE au même level, autour de 220–300 k$ de total comp à IC3. Les postes QA peu automatisés se placent 20 à 30 % en dessous, c'est l'argument financier pour passer la barre du coding. À Paris, un QA automaticien mid tourne autour de 45–60 k€ de base, éditeurs et scale-ups au-dessus des ESN ; gardez le chiffre US comme benchmark, pas comme attente locale.
Comment se préparer, cinq conseils tactiques
Ouvrez vos réponses comportementales avec la méthode STAR, Situation, Tâche, Action, Résultat. Les conseils tactiques ci-dessous s'appuient sur cette structure pour ce rôle précis.
- Bossez les LeetCode easy puis medium pendant 4 semaines et plus (tableaux, chaînes, hash maps). La barre coding SDET des grands groupes est juste sous celle des SWE, et c'est là que la plupart des candidats QA se font filtrer
- Construisez une petite suite Playwright sur une app de démo publique avant le process. Le round pratique note la stratégie de locators, les attentes et la gestion du flaky, et une réponse vécue ne sonne pas comme une réponse lue dans la doc
- Entraînez-vous à énumérer des cas de test à voix haute : prenez n'importe quelle feature et listez 20 cas en cinq minutes, groupés en nominal, bornes, permissions, modes de défaillance. Le round de test design note la structure ; le volume seul le perd
- Lisez les chapitres tests de Software Engineering at Google (gratuit en ligne, lien plus bas). Le vocabulaire small / medium / large et la logique de budget de flakiness viennent de là, et les interviewers utilisent les deux
- Préparez 4 à 5 histoires de bugs avec des chiffres : comment le bug a été trouvé, l'impact de l'échappée, et quel test ou quelle gate a changé ensuite. « J'ai trouvé beaucoup de bugs » vous classe junior
Les pièges fréquents au niveau QA
Quelques erreurs fréquentes qui font recaler les candidats QA même quand ils sont par ailleurs solides. Mieux vaut les repérer en mock interview avant qu'elles n'apparaissent en vrai.
Répondre au round de test design avec une longue liste plate de cas nominaux.
Pourquoi ça rate
Le round note la structure : d'abord les catégories de risque (bornes, permissions, concurrence, données invalides), puis les cas dans chacune. Vingt cas non hiérarchisés signalent une QA de checklist ; le signal d'embauche, c'est trouver les deux cas qui bloqueraient vraiment la release.
Comment rattraper
Groupez à voix haute avant d'énumérer : « je découpe en fonctionnel, bornes, permissions et modes de défaillance, et je commence là où le risque de release est le plus haut. » Puis remplissez. Cette phrase de découpage change à elle seule la notation du round.
Parler des tests flaky comme d'une chose qu'on relance plutôt que d'une chose qu'on possède.
Pourquoi ça rate
La gestion du flaky sépare le SDET du lanceur de scripts dans la plupart des loops. « On le relance et ça passe » dit à l'interviewer que la suite ne gate rien. Le vocabulaire attendu : quarantaine, root cause, et un budget de flakiness géré comme les SRE gèrent leurs error budgets.
Comment rattraper
Décrivez une politique plutôt qu'une anecdote : quarantaine au premier flake, root cause dans le sprint, taux de flakiness suivi dans le temps, et suppression des tests qui coûtent plus qu'ils n'attrapent.
Vous présenter comme la personne qui trouve les bugs plutôt que comme l'ingénieur qui les rend impossibles.
Pourquoi ça rate
Trouver les bugs, c'est la moitié junior du métier. La barre IC3, ce sont les systèmes : l'automatisation, les gates de CI et les chantiers de testabilité qui suppriment toute une classe d'échappées. Les histoires qui s'arrêtent à « donc j'ai ouvert le ticket » plafonnent l'évaluation de niveau.
Comment rattraper
Prolongez chaque histoire de bug d'un cran après le fix : le test, la gate ou le changement de code qui fait que cette classe de bug ne peut plus partir en prod. Ce dernier cran, c'est le signal de niveau.
Ressources recommandées
Livres, cours et outils qui reviennent le plus dans la préparation QA. Sans lien d'affiliation.
- 01Software Engineering at Google — chapitres tests →Gratuit en ligne. Les chapitres 11 à 14 sont la source des tailles de test small / medium / large et de la discipline anti-flaky sur lesquelles ce guide s'appuie ; les interviewers des grands groupes utilisent le même vocabulaire.
- 02Martin Fowler, The Practical Test Pyramid →La version canonique de la pyramide de tests que le round de design de framework attend. À citer directement quand vous défendez ce que vous automatisez.
- 03Google Testing Blog →Là où la politique anti-flaky se débat en public, y compris les posts derrière le réflexe quarantaine puis root cause décrit plus haut.
- 04Documentation Playwright →Le framework que la plupart des loops web supposent aujourd'hui. Les guides auto-waiting et locators répondent exactement aux questions du round pratique.
- 05Test Automation University →Cours structurés et gratuits d'Applitools. La rampe la plus rapide pour passer de la QA manuelle à l'automatisation.
Scénarios courants
Comment passer de la QA manuelle à un poste SDET quand mon poste actuel ne comporte aucune automatisation ?
Construisez la preuve vous-même, parce que l'entretien la demandera. Choisissez une stack (TypeScript + Playwright est le choix le plus sûr), automatisez 15 à 20 scénarios sur une app de démo publique, publiez le tout sur GitHub avec un README qui explique votre stratégie de locators et votre gestion des attentes et du flaky. Ce repo devient votre réponse à la moitié du round pratique. En parallèle, bossez les LeetCode easy puis medium pendant 8 à 12 semaines : les équipes automation-first filtrent au coding screen avant même de regarder vos compétences de test. Visez les intitulés SDET, QA Automation ou Test Engineer plutôt que QA Analyst ; les process correspondent à la prépa décrite dans ce guide. La certification ISTQB rassure les ESN et les DSI, mais pèse peu chez les éditeurs de logiciels.
Le coding d'un entretien SDET est-il aussi dur que celui d'un software engineer dans les grands groupes ?
Même pool de questions, un peu plus d'indulgence. Google, Amazon et Microsoft puisent les questions de coding SDET dans la banque SWE, surtout du LeetCode easy à medium sur les tableaux, les chaînes et les hash maps, et notent sur du code qui marche plus votre façon de le tester. Là où un candidat SWE doit trouver la solution optimale vite, un candidat SDET passe en général avec une solution correcte et propre, plus un vrai raisonnement de cas de test sur son propre code. Le piège, c'est de croire la barre basse : la plupart des candidats QA recalés échouent ici, pas sur les connaissances de test. Quatre semaines de drill quotidien suffisent ; le plan de prépa du guide met la moitié du temps sur le coding pour exactement cette raison.
Comment aborder un take-home QA qui demande d'automatiser un site de démo ?
Les relecteurs notent la structure, pas le nombre de scénarios. Cinq tests bien organisés battent vingt tests fragiles. Utilisez des page objects ou une séparation équivalente pour qu'un changement d'UI ne touche qu'un fichier, préférez des locators par rôle ou par texte aux chaînes CSS, appuyez-vous sur l'auto-waiting du framework plutôt que sur des sleeps, et écrivez des assertions assez précises pour échouer utilement. Puis passez 30 minutes sur le README : ce que vous couvrez, ce que vous laissez volontairement de côté, comment vous le brancheriez en CI, comment vous géreriez le flaky. Ce README fait souvent la différence, parce qu'il montre le jugement que l'entretien sur site devrait sinon aller chercher. Rendre un jour en avance avec une suite plus petite et plus propre est le bon arbitrage.
Que répondre quand l'interviewer demande pourquoi la QA plutôt que le développement ?
Répondez avec de l'appropriation, jamais avec des excuses. Les versions perdantes : « je vise un poste de développeur à terme » (vous quitterez la fonction) et « j'y suis arrivé par hasard » (personne ne vous a choisi). La version gagnante nomme ce que le métier possède en propre : vous êtes là où se prend la décision de release, vous construisez l'automatisation dont les autres ingénieurs dépendent, et vous êtes la personne qui sait comment le système casse vraiment. Si vous visez le développement un jour, gardez-le hors de ce process ; on recrute pour le poste en face de vous. Une histoire concrète de go / no-go tenu ou de classe de bugs éliminée porte mieux le message que n'importe quelle formule.
Questions fréquentes
J'ai cinq ans de QA manuelle. Ce guide s'applique-t-il à moi ?
Oui, et l'écart à combler est précis : le coding screen et le round pratique d'automatisation. Les rounds de test design et le comportemental joueront en votre faveur, la QA manuelle construit exactement les réflexes d'énumération de cas et de défense de bug que ces rounds notent. Prévoyez 8 à 12 semaines : un langage (Python ou TypeScript), des LeetCode easy puis medium, et une petite suite Playwright montée de bout en bout par vous. Les équipes automation-first filtrent au coding screen, c'est donc là que va le temps de prépa.
Combien de temps prévoir avant un onsite QA ?
Les process durent 3 à 5 semaines. Donnez-vous 6 à 8 semaines de prépa, à peu près moitié sur le coding screen, moitié sur un projet d'automatisation que vous pouvez défendre en détail. Entraînez-vous à énumérer des cas à voix haute ; c'est le round que les gens improvisent et perdent.
Quelle est l'erreur la plus fréquente des candidats au niveau QA ?
Sous-estimer le round de coding. Les candidats QA préparent la théorie du test puis se font filtrer par un LeetCode medium, parce que chez les grands groupes la barre coding SDET est juste sous celle des SWE. Quatre semaines de drill rapportent plus que n'importe quelle connaissance de framework.
Et si mon process d'entretien diffère de celui décrit ici ?
L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.
Comment ce guide se compare-t-il au scan gratuit ?
Ce guide couvre la barre générale au niveau L4 / IC3. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.
Prêt à préparer un vrai poste ?
Collez n'importe quelle offre QA, découvrez votre coach en moins de 30 secondes.
Déposez une URL LinkedIn, Greenhouse, Lever ou Levels.fyi, ou collez le texte de l'offre. Votre coach prédit les questions pour cette entreprise, fait ressortir vos écarts d'expérience, et calibre un benchmark de salaire pour le poste et la localisation. PDF par e-mail. L'entraînement vocal avec retour IA sur chaque réponse vit dans l'extension Chrome.
Gratuit, 8 crédits de coaching offerts · Sans carte bancaire · Votre CV reste sur votre appareil