Comment rédiger un CV d'ingénieur QA

Ce qu'un recruteur cherche en premier

Quelqu'un qui recrute un ingénieur QA ne lit pas votre CV de haut en bas au premier passage. Il cherche trois choses, dans cet ordre approximatif : ce que vous avez testé (le domaine — fintech, santé, e-commerce, embarqué, jeux), comment vous l'avez testé (manuel, automatisé, ou les deux, et à quelle couche — unitaire, API, UI, bout en bout), et avec quoi vous l'avez testé (les outils spécifiques nommés dans leur stack). Si ces trois éléments ne sont pas visibles dans le premier tiers de la page, le CV est mis de côté, car le lecteur en a une pile et une annonce qui nommait des outils précis pour une raison.

C'est pourquoi « souci du détail, esprit d'équipe et bonnes compétences en communication » en haut d'un CV QA est de l'espace perdu. Cela ne dit rien au lecteur qu'il ne puisse supposer, et cela repousse l'information utile — Selenium, Playwright, Postman, peu importe — plus bas dans la page où elle risque d'être manquée lors d'un survol.

Mettez votre stack d'automatisation et votre périmètre de test dans les premières lignes, soit sous forme de résumé court, soit comme ligne de compétences directement sous votre nom. Pas un nuage de compétences avec quarante outils par ordre alphabétique — la poignée que vous avez réellement utilisée en production, avec assez de précision pour que celui qui la lit sache immédiatement si vous correspondez à sa stack.

Qualifications et certifications : ce qu'elles signalent réellement

Le QA n'est pas une profession réglementée — il n'y a pas d'équivalent d'un examen du barreau ou d'une inscription à l'ordre infirmier. Personne ne vérifie un registre avant que vous puissiez vous appeler ingénieur QA. Cela signifie que les certifications fonctionnent ici différemment des domaines réglementés : elles sont un signal de formation formelle, pas une exigence légale, et les recruteurs varient beaucoup dans le poids qu'ils leur accordent.

L'ISTQB Foundation Level (et les niveaux supérieurs Advanced et Expert, si vous les avez) est la certification la plus susceptible d'être reconnue d'emblée par un recruteur QA, car c'est ce qui se rapproche le plus d'un vocabulaire partagé dans le domaine — niveaux de test, types de test, cycle de vie des défauts, la terminologie utilisée dans les plans de test. Elle ne vous obtiendra pas un entretien à elle seule, mais l'omettre si vous l'avez est une erreur : certains systèmes de suivi des candidatures et certains recruteurs filtrent effectivement dessus.

Au-delà de l'ISTQB, ce qui compte davantage, ce sont les certifications spécifiques aux outils et au cloud qui correspondent directement à l'annonce : certifications AWS ou Azure si le poste touche aux tests d'infrastructure cloud, un Certified Selenium Professional ou similaire si l'automatisation est centrale, des certifications en tests de sécurité comme OSCP ou CEH si le poste comporte un volet tests de sécurité (de plus en plus courant dans les annonces QA qui demandent des compétences proches de la pénétration). Listez-les près de votre nom ou dans une courte ligne « certifications », pas enfouies en bas sous l'éducation — un recruteur qui cherche une certification spécifique nommée dans l'annonce regardera d'abord en haut.

Un diplôme en informatique ou en génie logiciel aide mais n'est pas traité comme une barrière comme il pourrait l'être pour certaines disciplines d'ingénierie — de nombreux ingénieurs QA en activité viennent d'autres parcours techniques ou même non techniques, et les CV qui montrent un parcours de test clair tendent à l'emporter sur un diplôme manquant ou sans rapport. Si votre diplôme n'a aucun rapport avec le logiciel, ne vous en excusez pas et ne le justifiez pas — laissez la section expérience parler.

Comment prouver votre expérience de test

C'est là que la plupart des CV QA se trompent, et c'est la même erreur à chaque fois : lister des responsabilités au lieu de résultats de test. « Responsable des tests du module de paiement » ne dit rien au lecteur sur ce que vous avez réellement fait ou ce qui a changé à cause de cela.

Ce qu'un recruteur QA veut voir, pour chaque poste, c'est une combinaison de :

• Ce que vous avez testé et à quel niveau — unitaire, intégration, API, UI, bout en bout, performance, sécurité, accessibilité. Nommer le niveau dit au lecteur où vous vous situez dans la pyramide de test, ce qui est une distinction réelle dans ce domaine et affecte ce dont un poste a réellement besoin.
• Ce que vous avez trouvé et ce qui en est advenu. Pas un décompte de défauts seul (un nombre élevé de bugs peut signifier des tests approfondis ou une fonctionnalité mal construite — ce n'est pas une lecture sans ambiguïté positive), mais la forme du travail : classifications de gravité que vous avez utilisées, comment les défauts ont été triés, si vous avez rédigé les étapes de reproduction qui ont permis de livrer un correctif plus rapidement.
• Ce que vous avez automatisé, et l'avant-après. « Réduit le cycle de régression de trois jours d'exécution manuelle à une suite automatisée de deux heures » est concret et vérifiable en entretien, ce qui est exactement pourquoi cela fonctionne mieux que « amélioré l'efficacité des tests ».
• La couverture, quand vous pouvez l'énoncer honnêtement. Les pourcentages de couverture de test sont couramment cités sur les CV QA, mais ils sont un proxy de la rigueur, pas une preuve — un recruteur qui a fait ce travail demandera ce que l'outil de couverture mesurait et s'il s'agissait de couverture de ligne, de branche ou d'exigence. Si vous citez un chiffre, soyez prêt à dire ce qu'il mesurait.
• Votre position dans le processus de livraison. Avez-vous assumé la validation d'une livraison, ou exécuté des cas de test écrits par quelqu'un d'autre ? Avez-vous rédigé le plan de test, ou en avez-vous suivi un ? C'est l'un des signaux les plus clairs de séniorité en QA et il est régulièrement laissé implicite plutôt qu'énoncé.

Rédigez des cas de test et des rapports de bug comme vous les rédigeriez pour un vrai ticket : spécifique, reproductible, avec le résultat énoncé. Un recruteur qui a lu des milliers de tickets de bug vagues remarquera une puce de CV qui se lit comme tel.

Outils, frameworks et vocabulaire qui appartiennent à ce CV

Un générique « maîtrise des outils de test » est invisible. Nommez la stack réelle, car les noms d'outils font un vrai travail de filtrage, à la fois pour un humain qui survole la page et pour toute correspondance de mots-clés dans un système de suivi des candidatures.

Frameworks et outils d'automatisation : Selenium, Playwright, Cypress, Appium (pour mobile), TestNG, JUnit, PyTest — et avec quel langage vous les avez associés, car « Selenium » seul ne dit pas à un lecteur si vous l'avez écrit en Java, Python ou C#.

Tests API et couche service : Postman, REST Assured, SoapUI — nommez-les séparément de l'automatisation UI, car les tests API et les tests UI sont des compétences différentes et une annonce qui spécifie l'un vous dit lequel ils ont besoin.

Intégration CI/CD et pipeline : Jenkins, GitHub Actions, GitLab CI, CircleCI. Énoncer que votre suite automatisée tournait dans un pipeline, plutôt que déclenchée manuellement, signale une pratique de test plus mature qu'un script autonome lancé à la main.

Gestion des défauts et des tests : JIRA (et spécifiquement si vous avez utilisé Xray ou Zephyr avec), TestRail, qTest. Ceux-ci valent la peine d'être nommés car différentes équipes QA standardisent sur différents outils, et la familiarité avec l'outil spécifique dans l'annonce élimine le frottement d'intégration auquel le recruteur pense.

Tests de performance et de charge : JMeter, Gatling, k6 — vaut une ligne séparée si vous l'avez, car c'est un ensemble de compétences distinct des tests fonctionnels et souvent ce qui sépare un ingénieur QA intermédiaire d'un senior.

Tests d'accessibilité : axe, WAVE, ou tests manuels de conformité WCAG — de plus en plus demandés et rarement listés, ce qui fait qu'ils valent la peine d'être inclus si vous les avez vraiment faits.

Contrôle de version et vocabulaire d'environnement : Git, Docker, environnements de staging versus production, feature flags. Les ingénieurs QA qui peuvent parler de comment ils ont testé à travers les environnements, pas seulement de ce qu'ils ont testé, se lisent comme plus seniors.

Ce qui est omis, et ne devrait pas l'être

Quelques éléments que les ingénieurs QA omettent régulièrement, non par malhonnêteté mais parce qu'ils ne pensent pas à les mentionner :

L'échelle de ce que vous avez testé. Nombre de cas de test maintenus, taille de la suite de régression, nombre d'environnements ou de combinaisons navigateur/appareil couverts. Ces chiffres sont concrets et donnent au recruteur un sens de la taille de l'opération sans avoir à demander.

Si vous avez travaillé dans une équipe Agile et quel était votre rôle dans le cycle de sprint — rédaction de critères d'acceptation, tests pendant le sprint versus après, participation à la planification ou aux rétrospectives de sprint. L'implication du QA dans les cérémonies Agile varie beaucoup entre entreprises et vaut la peine d'être énoncée plutôt que supposée.

Travail transversal avec les développeurs. Si vous avez fait du pair programming avec des développeurs sur du développement piloté par les tests, revu des pull requests, ou écrit des tests qui tournaient dans le workflow du développeur plutôt qu'une passe QA séparée. Cette distinction — QA comme porte en fin versus QA intégré au développement — est quelque chose que les recruteurs filtrent activement, et elle est rarement énoncée clairement.

Tout test exploratoire que vous avez fait, distinct de l'exécution de cas de test scriptés. C'est une compétence réelle et valorisée dans ce domaine et elle n'apparaît pas dans un décompte de tests automatisés, donc elle doit être énoncée directement ou elle est invisible.

Que faire ensuite

Mettez l'annonce d'emploi à côté de votre CV et vérifiez que les outils spécifiques, niveaux de test et certifications qu'elle nomme apparaissent sur votre CV dans les mêmes mots, près du haut. Réécrivez vos trois postes les plus récents comme résultats de test, pas responsabilités — ce que vous avez testé, ce que vous avez trouvé, ce que vous avez automatisé, et ce qui a changé en conséquence. Coupez le paragraphe de résumé qui pourrait décrire n'importe quel ingénieur et remplacez-le par votre stack et domaine réels.

Si vous envoyez des CV plus vite que vous ne pouvez les adapter à ce que chaque annonce demande spécifiquement, c'est généralement de là que vient le silence — pas de la qualité du travail derrière le CV. jobmarket.pro lit chaque annonce intégralement, la compare à un profil dans lequel il ne peut inventer d'expérience, et prépare la candidature à partir de cela.