Top 50 Questions d'Entretien QA Engineer en 2026 (Avec Réponses)

Les entretiens QA en 2026 testent trois choses : les fondamentaux (parler clairement des concepts de test), les compétences techniques (écrire du code et raisonner dessus), et le jugement. Le jugement, c'est prendre la bonne décision quand il n'y a pas de réponse évidente.

Fondamentaux du test

La vérification pose la question : "construisons-nous le produit correctement ?" en vérifiant que le produit correspond aux spécifications, aux designs et aux exigences. La validation demande si nous construisons le bon produit, en vérifiant que le produit résout réellement le problème de l'utilisateur.

Réponse faible : "La vérification vérifie le code, la validation vérifie le produit." C'est vague et confond les deux.

Réponse forte : "La vérification est interne : le build correspond-il à ce qui a été spécifié ? La validation est externe, elle pose la question de si ce que nous avons construit satisfait réellement le besoin de l'utilisateur. Un produit peut passer la vérification (il correspond exactement à la spec) et échouer la validation (la spec se trompait sur ce dont les utilisateurs avaient besoin)."

Un scénario de test est une description de haut niveau de ce qu'il faut tester, comme "l'utilisateur peut se connecter avec des identifiants valides." Un cas de test est l'implémentation détaillée étape par étape : entrées exactes, sorties attendues, préconditions, postconditions.

Le smoke testing est un passage superficiel sur les fonctionnalités les plus critiques après un build. L'application démarre-t-elle, les utilisateurs peuvent-ils se connecter, le flux principal fonctionne-t-il ? L'objectif est de décider rapidement si le build vaut la peine d'être testé davantage.

Les tests de régression vérifient que les fonctionnalités existantes fonctionnent encore après de nouvelles modifications. Ils sont plus larges et plus lents, car vous protégez ce qui fonctionnait déjà contre les risques introduits par le nouveau code.

Le test exploratoire est un apprentissage, une conception de tests et une exécution simultanés. Au lieu de suivre un script prédéfini, le testeur explore l'application, utilise ce qu'il apprend pour guider où chercher ensuite, et s'adapte en temps réel. C'est utile pour trouver des bugs que les tests scriptés ne couvrent pas parce que personne n'a pensé à écrire un cas de test pour eux.

Le test black-box traite le système comme une boîte noire : vous connaissez uniquement les entrées et les sorties attendues, pas l'implémentation interne. Le test white-box utilise la connaissance du code interne, donc vous écrivez des tests basés sur les chemins de code, les branches et la logique.

La plupart des ingénieurs QA font du test black-box. La connaissance white-box est utile pour comprendre quels cas limites tester.

Conception de tests

Test basé sur les risques : prioriser par probabilité d'échec et impact de l'échec. Un flux de paiement qui échoue est à fort impact. Un "tooltip au survol" qui échoue est à faible impact. Une nouvelle fonctionnalité a une probabilité d'échec plus élevée qu'une fonctionnalité stable qui n'a pas changé depuis des mois.

Réponse faible : "Je teste tout de façon approfondie." Personne ne teste tout. Le temps et les pipelines de build ne le permettent pas.

Réponse forte : "Je commence par comprendre ce qui a changé et ce qui présente le plus de risque. Le nouveau code reçoit plus de couverture que le code inchangé. Les flux côté utilisateur reçoivent plus de couverture que les flux admin uniquement. Je parlerais aussi au développeur pour comprendre quels cas limites l'incertifient le plus."

Le partitionnement par équivalence divise l'espace d'entrée en groupes où toutes les valeurs du groupe se comportent de la même façon. Au lieu de tester chaque âge possible, vous testez une valeur de chaque partition : moins de 18 ans, 18 à 65 ans, plus de 65 ans.

L'analyse des valeurs limites teste les bords de ces partitions (17, 18, 65, 66) parce que les bugs se regroupent aux frontières. Le code qui gère "18 à 65" correctement a souvent une erreur de décalage de un exactement à 18 ou 65.

Une bonne réponse inclut : le chemin nominal (identifiants valides, succès) et les chemins négatifs (mauvais mot de passe, nom d'utilisateur incorrect, champs vides, injection SQL, entrées très longues). Elle couvre aussi les cas limites (longueur minimale et maximale des champs) et les considérations non fonctionnelles comme un double-clic sur le bouton de soumission.

Titre (concis, décrit le problème), environnement (navigateur, OS, version de l'application), étapes de reproduction (exactes, numérotées), résultat attendu, résultat réel, sévérité/priorité, et pièces jointes (capture d'écran, vidéo, logs réseau si pertinents).

Automatisation

Automatisez quand : le test est exécuté fréquemment (régression), les données sont cohérentes et le scénario est stable. L'automatisation doit économiser plus de temps qu'elle n'en coûte à construire et maintenir.

N'automatisez pas quand : le test requiert un jugement humain (utilisabilité, design visuel) ou quand la fonctionnalité change à chaque sprint. Évitez aussi d'automatiser un test exécuté une seule fois, comme une vérification de migration de données ponctuelle.

POM est un design pattern qui encapsule les interactions de page dans une classe. Au lieu d'appeler page.getByLabel('Email').fill(email) dans chaque test, vous créez une classe LoginPage avec une méthode login(email, password). Les tests appellent la méthode ; quand le formulaire de connexion change, vous le corrigez à un seul endroit.

Les tests unitaires à la base : nombreux, rapides, peu coûteux à écrire et exécuter. Ils testent des fonctions et composants individuels. Les tests d'intégration au milieu sont moins nombreux et testent les interactions entre composants. Les tests end-to-end au sommet sont les moins nombreux et les plus lents, et testent les flux utilisateurs complets via l'interface.

La forme pyramidale compte. L'inverser (surtout des tests E2E) vous donne un feedback lent, un coût de maintenance élevé et des suites flaky.

Les tests flaky échouent aléatoirement sur le même code. Causes courantes : problèmes de timing (élément pas prêt quand le test agit dessus), pollution de tests (état qui fuit entre les tests), conflits d'exécution parallèle (deux tests modifiant les mêmes données simultanément).

Correction : pour le timing, utilisez des attentes appropriées (attendre des conditions spécifiques, pas des délais fixes). Pour la pollution, assurez-vous que chaque test configure et nettoie son propre état. Pour les conflits parallèles, utilisez des données de test uniques par test ou exécutez les tests en conflit séquentiellement.

Questions spécifiques à Playwright

Chaque action Playwright attend automatiquement que l'élément cible atteigne un état "actionnable" avant de procéder. Pour click() : l'élément doit être visible, stable et activé. Pour fill(), l'élément doit être éditable. Cette attente se fait automatiquement avec un timeout configurable (30 secondes par défaut).

Utilisez storageState. Connectez-vous une fois dans un fichier de setup, sauvegardez les cookies d'authentification et le localStorage du navigateur dans un fichier JSON, puis configurez chaque test pour charger cet état :

// Setup global : se connecte et sauvegarde l'état d'auth
await page.context().storageState({ path: 'auth.json' });

// playwright.config.ts
use: {
  storageState: 'auth.json'
}

Chaque test démarre déjà authentifié sans passer par l'interface de connexion.

Agile et processus

Le QA doit être impliqué dès le début : revoir les exigences et les critères d'acceptation pendant le planning, poser des questions pendant le refinement. Il faut aussi écrire ou revoir les cas de test avant que le développement commence. Les tests ne doivent pas démarrer uniquement quand le développement est "terminé." Ça crée un goulot d'étranglement en fin de sprint.

Déplacer les activités de test plus tôt dans le processus de développement. Au lieu de tester une fois le code terminé, vous revoyez les exigences pour leur testabilité et écrivez des cas de test pendant le développement. Les tests s'exécutent dans le cadre du processus de build. L'objectif est de trouver les défauts plus tôt quand ils sont moins coûteux à corriger.

Apportez des preuves : étapes de reproduction exactes, comportement attendu d'après les exigences ou le design, et le comportement réel. Si c'est genuinement ambigu (pas dans la spec), escaladez au product owner qui peut décider si le comportement actuel est acceptable. Ne discutez pas. Documentez.

Évaluez l'impact : qui ça touche, à quelle fréquence, existe-t-il une solution de contournement ? Escaladez immédiatement au team lead et au product owner avec l'évaluation d'impact. Ne bloquez pas silencieusement la release. La décision de livrer, retarder ou hotfixer appartient au product owner, pas au QA. Votre rôle est de signaler le risque clairement et rapidement.

Carrière et situationnelles

QA Engineer se concentre sur la stratégie de test, l'exécution des tests et le processus qualité. SDET (Software Development Engineer in Test) est un rôle à plus forte composante ingénierie : construction de frameworks de test, infrastructure de test, pipelines CI/CD et outillage de test. Les SDETs écrivent du code de qualité production pour les systèmes de test, pas seulement des scripts de test.

En pratique, les titres se recoupent et les entreprises les utilisent différemment. Regardez la description de poste, pas le titre.

Structurez avec STAR : Situation (ce qui était en cours de release), Tâche (votre rôle), Action (comment vous l'avez trouvé, ce que vous avez fait), Résultat (ce qui s'est passé). Soyez précis, avec des chiffres, des délais et l'impact réel. "J'ai trouvé un bug qui aurait touché tous les utilisateurs du checkout et nous avons retardé la release pour le corriger" vaut mieux que "j'ai trouvé un bug important une fois."

Citez des choses précises : des blogs que vous lisez (Ministry of Testing, changelog Playwright), des conférences (TestBash), des newsletters, des cours que vous avez suivis. "Je lis des articles en ligne" est une réponse faible. Des sources spécifiques et des exemples sont forts.