Entretien Testeur / QA : les questions à préparer
· 8 min
Le métier de testeur souffre d'un malentendu tenace : beaucoup de candidats se présentent comme des exécutants de plans de test. Les recruteurs, eux, cherchent quelqu'un capable de dire ce qui vaut la peine d'être testé — et ce qui n'en vaut pas la peine.
Que cherche vraiment un recruteur chez un testeur ?
Trois aptitudes, dans cet ordre. Savoir prioriser sous contrainte de temps, parce qu'on ne teste jamais tout. Savoir décrire un défaut de façon reproductible, parce qu'un rapport flou coûte plus cher qu'il ne rapporte. Et savoir dire non à une mise en production, ce qui suppose d'assumer un désaccord.
Quelles questions techniques reviennent le plus ?
- La différence entre test fonctionnel, test de non-régression et test de recette : on vérifie que le vocabulaire est maîtrisé, pas récité.
- Ce que vous automatisez et ce que vous laissez manuel — et surtout pourquoi. Une réponse « tout automatiser » est un signal d'alarme.
- La pyramide de tests : unitaires, intégration, bout en bout. On attend que vous sachiez pourquoi la base doit être large.
- Un cas de test que vous jugez mal écrit, et comment vous le réécririez.
- Votre rapport à la couverture de code : savoir qu'une couverture de 90 % ne dit rien de la qualité des assertions.
Comment se déroule la mise en situation ?
C'est l'exercice qui départage. On vous donne une fonctionnalité simple — un formulaire d'inscription, un panier — et on vous demande ce que vous testeriez. Le piège est de partir dans les cas nominaux. Ce qu'on écoute, ce sont les cas limites que vous voyez spontanément : champ vide, double soumission, caractères spéciaux, retour arrière du navigateur, session expirée en cours de saisie.
Faut-il maîtriser l'automatisation pour être recruté ?
Pas toujours, mais il faut savoir en parler. Beaucoup d'offres demandent un outil précis — Selenium, Cypress, Playwright — alors que l'équipe cherche surtout quelqu'un qui comprend ce qu'un test automatisé coûte à maintenir. Si vous ne connaissez pas leur outil, dites-le, puis expliquez celui que vous connaissez : la transposition se démontre, elle ne se prétend pas.
Comment répondre à « avez-vous déjà laissé passer un bug en production ? »
Par oui. Répondre non détruit votre crédibilité en une phrase : tout le monde en a laissé passer. Ce qui est évalué, c'est la suite — comment vous l'avez découvert, ce que vous avez changé ensuite dans votre façon de tester, et si le correctif a produit un test de non-régression. La méthode STAR structure très bien ce type de réponse.
Le comportemental pèse-t-il autant que la technique ?
Davantage, à niveau technique égal. Un testeur passe sa journée à annoncer de mauvaises nouvelles à des gens pressés. On vous demandera comment vous réagissez quand un développeur conteste votre rapport, ou quand un chef de projet vous demande de valider malgré un défaut ouvert. Préparez ces deux réponses : elles tombent presque à chaque fois.
Un bon testeur ne dit pas « ça ne marche pas ». Il dit ce qui ne marche pas, dans quelles conditions, et à quel point c'est grave.
Comme pour tout entretien technique, l'écart se creuse à l'oral : savoir tester et savoir l'expliquer sont deux compétences distinctes. Voyez aussi notre article sur les questions difficiles en entretien et la méthode pour se renseigner sur une entreprise avant un entretien.