Comment Se Préparer pour un Entretien Technique QA: Guide Étape par Étape

Les entretiens techniques QA en 2026 couvrent quatre domaines : les concepts de test fondamentaux, Playwright et l'automatisation des tests, SQL, et un exercice de code en direct. Durant cet exercice, vous écrivez ou déboguez des tests en temps réel.

Ce que couvrent vraiment les entretiens techniques QA

Avant de préparer, comprenez le format. Les entretiens techniques QA en 2026 se composent généralement de :

| Étape | Ce qui est évalué | Durée |

|-------|------------------|-------|

| Entretien recruteur | Parcours, motivation, bases | 20-30 min |

| Test technique | Concepts QA, outils, expérience | 45-60 min |

| Code en direct / automatisation | Écrire des tests Playwright, déboguer | 45-60 min |

| Conception de systèmes (postes senior) | Stratégie de test, architecture | 45-60 min |

| Comportemental | Expérience passée, compétences relationnelles | 30-45 min |

Toutes les entreprises ne font pas toutes ces étapes : les plus petites les combinent souvent. Connaître les catégories aide à allouer le temps de préparation.

Étape 1 : Identifiez le niveau que vous visez (Semaine 1)

La profondeur des questions techniques évolue avec le niveau de séniorité. Avant d'étudier, soyez honnête sur le niveau qui vous correspond.

• Playwright de base : locators, assertions, structure de test basique
• Fondamentaux du rapport de bug
• Compréhension des types de tests (smoke, régression, sanity)
• Bases de l'Agile
• Tests manuels : quoi, pourquoi, quand

• Tout ce qui précède, en plus approfondi
• Tests d'API : codes de statut, requête/réponse, API request de Playwright
• Conception de tests : partitionnement en classes d'équivalence, analyse des valeurs limites
• CI/CD : GitHub Actions, pipelines de test
• Page Object Model

• Stratégie de test et décisions d'architecture
• Construction et maintenance de frameworks d'automatisation
• Tests basés sur les risques et priorisation sous contraintes
• Influence d'équipe et amélioration des processus
• Notions de tests de performance et de sécurité

Étape 2 : Faites le bilan de vos lacunes (Semaine 1)

Faites un inventaire honnête. Pour chaque item, notez : maîtrisé / fragile / ne sais pas.

Playwright :

• [ ] Initialiser un nouveau projet Playwright
• [ ] Locators : getByRole, getByTestId, getByLabel, getByText
• [ ] Assertions : toBeVisible, toHaveText, toContainText, toHaveValue
• [ ] test.beforeEach et test.afterEach
• [ ] Fixtures : utiliser les built-in, créer des custom
• [ ] Pattern Page Object Model
• [ ] Tests d'API avec la fixture request
• [ ] Interception réseau avec route.fulfill
• [ ] Lancer les tests en mode headed/headless
• [ ] Lire et interpréter le rapport HTML

Concepts de test :

• [ ] Partitionnement en classes d'équivalence et analyse des valeurs limites
• [ ] Tests boîte noire vs boîte blanche
• [ ] Tests smoke, régression, sanity : différences
• [ ] Pyramide de tests et où se situent les différents types
• [ ] Tests basés sur les risques et priorisation
• [ ] Shift-left testing
• [ ] Définition du "terminé" du point de vue QA

API et web :

• [ ] Méthodes HTTP (GET, POST, PUT, PATCH, DELETE)
• [ ] Codes de statut (200, 201, 400, 401, 403, 404, 422, 500)
• [ ] Structure d'une requête : headers, body, paramètres de query
• [ ] Ce qu'est un token JWT
• [ ] Fonctionnement des cookies de navigateur

Tout ce qui est dans "fragile" ou "ne sais pas" constitue votre liste d'étude.

Étape 3 : Étudiez les bons sujets (Semaines 1-2)

Les fondamentaux de Playwright

Ne vous contentez pas de lire : écrivez du code. Créez un projet de pratique :

npm init playwright@latest

Choisissez un site de pratique public (lab.becomeqa.com, the-internet.herokuapp.com, automationpractice.pl) et écrivez des tests pour :

• Un formulaire de connexion (identifiants valides, invalides)
• Un formulaire avec plusieurs champs et validation
• Un tableau : vérifier les données, le tri, le filtrage
• Un endpoint API avec request

Si vous écrivez 5 à 10 tests Playwright de zéro sur un vrai site, vous êtes en avance sur la plupart des candidats.

Le rapport de bug

Soyez prêt à rédiger un rapport de bug sur le moment. Entraînez-vous à écrire :

• Un titre clair (pas "la connexion ne fonctionne pas" : "Le bouton de connexion ne répond pas quand l'e-mail contient des majuscules")
• Les étapes de reproduction (numérotées, précises)
• Le comportement attendu vs réel
• L'environnement (navigateur, OS, version)
• La sévérité et la priorité

La conception de tests

Sachez appliquer au moins un exemple de partitionnement en classes d'équivalence et d'analyse des valeurs limites. L'exemple du champ âge (0, 1, 17, 18, 120, 121) est bon à intérioriser.

Le vocabulaire de la théorie du test

Soyez capable d'expliquer clairement, sans définitions mémorisées :

• Qu'est-ce que les tests de régression ?
• Différence entre sévérité et priorité
• Qu'est-ce qu'un cas de test vs un scénario de test ?
• Qu'est-ce que le shift-left testing ?
• Qu'est-ce qu'un test flaky et pourquoi ça arrive ?

Étape 4 : Entraînez-vous au code en direct (Semaines 2-3)

C'est là que la plupart des candidats perdent des points. Ils connaissent Playwright conceptuellement mais se bloquent quand on leur demande d'écrire un test en temps réel.

• "Je vais localiser le champ e-mail par son test ID..."
• "J'affirme que le message d'erreur est visible..."
• "Je devrais aussi gérer le cas où la connexion réussit et vérifier la redirection..."

Les recruteurs valorisent la réflexion, pas seulement le résultat.

1. Écrire un test Playwright pour un formulaire de connexion

2. Écrire un test qui appelle une API et vérifie la réponse

3. Déboguer un test en échec (on vous montre du code avec un bug)

4. Ajouter un test pour un cas limite spécifique qu'on vous décrit

• "Je ne suis pas sûr à 100 % de la syntaxe exacte ici, mais l'approche serait..."
• "Je devrais vérifier la documentation Playwright pour cette assertion précise, mais je sais qu'elle existe..."

Admettre une incertitude avec élégance vaut bien mieux que de deviner et s'entêter.

Étape 5 : Préparez vos anecdotes (Semaine 3)

Les questions comportementales nécessitent des exemples concrets. Avant l'entretien, notez brièvement :

1. Un bug critique que vous avez trouvé avant une release

2. Un moment où vous étiez en désaccord avec un développeur sur un bug (et comment vous l'avez résolu professionnellement)

3. Un moment où vous avez dû tester sous pression de temps : ce que vous avez priorisé

4. Une amélioration de processus que vous avez introduite ou suggérée

5. Un bug manqué qui est arrivé en production (et ce que vous en avez appris)

Si vous n'avez pas 5 ans d'expérience, vous pouvez utiliser des projets académiques, des projets personnels, ou même des situations très junior. L'important, c'est la précision, pas le niveau de séniorité.

Étape 6 : Renseignez-vous sur l'entreprise (Semaines 3-4)

Les réponses génériques donnent des résultats génériques. Pour chaque entreprise :

• Que fait leur produit ? (Utilisez-le avant l'entretien)
• Quelle stack technique mentionne l'offre d'emploi ?
• Se concentrent-ils sur le web, le mobile, l'API, les performances ?
• Que dit leur blog technique ou LinkedIn sur leurs processus ?

Adapter même une ou deux réponses au contexte de l'entreprise montre un engagement réel.

Le jour de l'entretien

Test technique : conseils de communication

• Pensez à voix haute. Le silence est pire qu'une réflexion imparfaite.
• Posez des questions de clarification : "Dois-je supposer que l'utilisateur est déjà connecté ?" "Testons-nous ça en isolation ou de bout en bout ?"
• Si vous ne savez pas, dites-le et expliquez ce que vous feriez pour trouver la réponse.
• Après avoir répondu, ajoutez : "Y a-t-il un point particulier sur lequel vous souhaitez que j'approfondisse ?"

Code en direct : conseils de préparation

Si vous pouvez utiliser votre propre éditeur, ayez un projet Playwright déjà configuré avec un fichier de test vide prêt à l'emploi. Dans un éditeur partagé, annoncez votre approche : "je commence par le squelette du test et je remplis les locators ensuite." Gardez toujours les assertions claires et délibérées, en nommant ce que vous affirmez et pourquoi.

Questions à poser au recruteur

Ces questions montrent une réflexion stratégique, pas seulement des connaissances techniques :

• "Comment l'équipe QA gère-t-elle actuellement les tests de régression : automatisés, manuels, ou les deux ?"
• "Quel est le plus grand défi qualité auquel l'équipe fait face en ce moment ?"
• "Comment les ingénieurs QA collaborent-ils avec les développeurs ? Les tests font-ils partie de la définition du terminé ?"
• "À quoi ressemble la pyramide de tests pour votre produit ?"

Ce que les recruteurs cherchent vraiment

Au-delà des questions techniques, les recruteurs évaluent :

Planning sur 4 semaines en un coup d'œil

| Semaine | Objectif |

|---------|---------|

| 1 | Évaluer les lacunes, revoir les bases Playwright, écrire 3-5 tests de pratique |

| 2 | Étude approfondie des points faibles, s'entraîner à expliquer les concepts à voix haute |

| 3 | Pratique du code en direct, préparer les anecdotes comportementales, se renseigner sur les entreprises |

| 4 | Entretiens blancs, révision, rafraîchissement ciblé des zones fragiles |

Les candidats embauchés ne sont généralement pas ceux qui en savent le plus. Ce sont ceux qui communiquent bien, pensent systématiquement, et montrent un engagement sincère envers la qualité comme métier. Si vous pouvez expliquer pourquoi un bug manqué est arrivé en production et ce que vous feriez différemment, vous êtes déjà plus avancé que la plupart des candidats.