Day in the Life of a QA Engineer

Vous voulez savoir à quoi ressemble vraiment une journée de QA Engineer, sans le discours de recrutement. Voici le déroulé concret, heure par heure quand c'est possible, et les zones floues quand ça ne l'est pas.

Je parle ici d'un profil intermédiaire, trois à cinq ans d'expérience, dans une équipe produit de taille moyenne. Les startups à dix personnes et les grands groupes ont des rythmes différents. Les grandes lignes restent proches.

Le matin : trier avant de tester#

La journée commence rarement par tester. Elle commence par comprendre ce qui a bougé depuis la veille.

Vous ouvrez le gestionnaire de tickets, Jira ou Linear dans la plupart des équipes. Vous regardez les builds de la nuit, les tests automatisés qui ont échoué, les commentaires laissés par les développeurs. Un test en rouge peut être un bug, ou un test mal écrit, ou une infrastructure qui a toussé. Cette distinction prend du temps.

Ensuite vient la question qui structure la matinée : qu'est-ce qui doit être vérifié aujourd'hui pour livrer ? Vous priorisez. Vous ne testez pas tout. Vous testez ce qui bloque la sortie.

Un point court avec l'équipe, quinze à trente minutes, souvent en visio. On annonce ce qu'on va couvrir, on signale les risques. Puis place au travail de fond.

La part réunion, la part travail profond#

C'est la question qu'on me pose le plus. La réponse honnête : ça dépend de la semaine, et ça varie plus que les gens ne l'imaginent.

Sur une semaine calme, comptez autour de 20 à 25 % de réunions. Le reste est du travail de fond : écriture de tests, exécution, investigation d'un bug, revue de code de tests. Pendant un lancement ou une phase de recette tendue, les réunions montent vite à 40 ou 50 %. Les appels se multiplient, les gens veulent des nouvelles toutes les deux heures.

Le travail profond, lui, demande du calme. Investiguer un bug intermittent pendant une heure sans interruption, c'est normal. Se faire interrompre trois fois pendant ce travail, c'est ce qui fait que la journée part en vrille.

Les QA seniors protègent leurs créneaux de concentration. Les juniors acceptent toutes les réunions et finissent épuisés sans savoir pourquoi.

Les outils que vous utilisez vraiment#

Oubliez les listes de vingt outils. Voici ce qui occupe réellement votre journée.

Un gestionnaire de tickets. Un dépôt de code avec Git. Un outil de tests automatisés, Cypress ou Playwright pour le web, Appium pour le mobile, parfois Selenium encore. Un outil de suivi des tests manuels si l'équipe en a un. Un navigateur avec ses outils de développement ouverts en permanence.

À cela s'ajoutent les outils de l'équipe : Slack ou Teams, un logiciel de visioconférence, parfois Postman ou un client similaire pour tester des API directement. Les équipes qui font de l'API testing passent plus de temps là-dessus que sur l'interface.

Ce qui surprend les nouveaux venus : vous passez beaucoup de temps à lire du code. Pas à l'écrire toujours, mais à le lire pour comprendre ce qui a changé et où le bug peut se cacher. Un QA qui ne lit pas de code reste bloqué au niveau surface.

Exemple concret : un bug intermittent#

Prenons un cas réel type. Un test automatisé échoue une fois sur trois. Personne ne sait pourquoi.

Vous regardez d'abord les logs. Vous cherchez un pattern horaire, une dépendance externe, un état partagé entre tests. Vous exécutez le test en local dix fois de suite. Vous ajoutez des logs supplémentaires. Vous regardez les modifications récentes dans le code concerné.

Au bout de deux heures, vous avez une hypothèse : le test utilise un compte de test partagé avec un autre scénario, et l'ordre d'exécution n'est pas garanti. Vous isolez le compte, vous relancez. Le test passe. Vous documentez le problème et vous en parlez au développeur concerné.

Ce genre de travail est invisible dans les comptes rendus. C'est pourtant une bonne partie du métier.

Les points de pression#

Le stress vient rarement du test lui-même. Il vient du calendrier.

Quand la date de livraison approche et que la qualité n'est pas au rendez-vous, le QA est en première ligne. On lui demande son avis : est-ce qu'on livre ou pas ? C'est une position inconfortable, surtout quand la réponse honnête est non.

Un autre point de pression : les bugs trouvés tard. Chaque bug découvert en fin de cycle coûte plus cher à corriger. Si vous avez testé tôt et souvent, vous réduisez ce risque. Si vous n'avez commencé à tester qu'après la fin du développement, vous allez souffrir.

Il y a aussi la pression silencieuse : celle de passer pour celui qui bloque toujours. Dire non à une livraison demande du courage et une bonne relation avec l'équipe. Les meilleurs environnements traitent le QA comme un partenaire, pas comme un gardien de portail.

Ce qui surprend les nouveaux venus#

Trois choses reviennent souvent.

La quantité de documentation. Vous écrivez des cas de test, des comptes rendus, des descriptions de bugs détaillées. Un bug bien décrit, avec étapes de reproduction, environnement, logs et comportement attendu, se corrige deux fois plus vite qu'un message de trois lignes.

La part de diplomatie. Signaler un bug demande du tact. Le développeur qui a écrit ce code est souvent dans la même réunion. Savoir formuler les choses sans accuser est un vrai savoir-faire.

L'absence de certitude absolue. Vous ne pouvez jamais prouver qu'un logiciel est sans bug. Vous pouvez réduire le risque. Accepter cette limite est difficile pour les profils qui aiment le noir et blanc.

Junior, intermédiaire, senior : ce qui change#

Au début, on exécute des tests écrits par d'autres. On apprend les outils, on découvre les processus, on pose beaucoup de questions. C'est normal et nécessaire.

Au niveau intermédiaire, on conçoit ses propres tests, on automatise certains scénarios, on commence à voir les risques avant qu'ils deviennent des bugs. On mène une partie de la recette sans supervision constante.

Chez un senior, le travail change de nature. Moins d'exécution, plus de stratégie : quels risques couvrir en priorité, quel périmètre automatiser, comment construire une suite de tests qui tient dans le temps. Le senior passe aussi du temps à faire grandir les autres et à défendre la qualité auprès de la direction.

Un QA senior expérimenté passe peut-être un tiers de son temps à écrire ou exécuter des tests. Le reste est de l'analyse, de la conception et de la communication. Si vous n'aimez pas ces aspects, le métier devient vite frustrant.

Comment préparer sa candidature#

Si vous visez ce poste, voici ce qui compte concrètement sur un CV.

• Décrivez les types de tests que vous avez menés : fonctionnels, de non-régression, API, performance, exploratoires.
• Nommez les outils que vous maîtrisez réellement, pas ceux que vous avez vus passer en formation.
• Montrez un exemple de bug que vous avez isolé et documenté, avec le résultat obtenu.
• Si vous automatisez, indiquez le langage, le framework, et la taille de la suite de tests que vous maintenez.
• Ajoutez toute expérience de travail direct avec des développeurs pour reproduire ou corriger un problème.

Un exemple de reformulation, avant et après.

Avant : "Responsable des tests sur l'application mobile."

Après : "Conception et exécution des tests de non-régression sur une application mobile, environ 120 cas de test, dont 45 automatisés avec Appium. Réduction des bugs en production observée après mise en place de la suite automatisée."

La deuxième version donne des repères. On comprend le volume, les outils, l'impact. Vérifiez votre CV avec un outil de vérification ATS gratuit pour éviter les problèmes de formatage, et utilisez un analyseur d'offre d'emploi pour comprendre ce que l'employeur demande vraiment.

Où trouver des offres réalistes#

Les intitulés varient : QA Engineer, Test Engineer, Ingénieur qualité logicielle, SDET pour les profils très orientés automatisation. Les attentes ne sont pas les mêmes selon l'intitulé. Un poste SDET demande beaucoup plus de développement qu'un poste de testeur manuel.

Pour explorer les offres disponibles et voir ce que les entreprises demandent concrètement, consultez les offres d'emploi du secteur tech. Les descriptions d'offres réelles donnent une meilleure image du métier que n'importe quel article. D'autres ressources pratiques sont disponibles sur le blog de jobrise.

Outils gratuits#

• jobrise.io/fr/free-ats-checker/
• jobrise.io/fr/free-jd-decoder/
• jobrise.io/fr/jobs/
• jobrise.io/fr/blog/

Questions fréquentes#

Faut-il savoir coder pour devenir QA Engineer ?

Pas au tout début, mais c'est de plus en plus attendu. Les postes purement manuels existent encore, souvent en début de carrière ou dans des contextes très spécifiques. Pour évoluer, savoir lire du code et écrire des tests automatisés devient rapidement nécessaire.

Quelle est la différence entre QA Engineer et testeur logiciel ?

Les deux intitulés se recoupent souvent, et les entreprises ne les utilisent pas toujours de la même manière. En général, le testeur exécute des cas de test définis, tandis que le QA Engineer conçoit la stratégie de test et automatise davantage. Lisez toujours la description de poste, l'intitulé seul ne dit pas grand-chose.

Combien de temps avant d'être opérationnel dans un nouveau poste ?

Comptez souvent un à trois mois avant de comprendre le produit, les processus et l'historique technique. Les applications complexes demandent plus de temps, parfois six mois avant de sentir à l'aise. Ne paniquez pas si vous êtes perdu les premières semaines, c'est attendu.

Le métier est-il menacé par l'automatisation et l'IA ?

L'automatisation remplace certaines tâches d'exécution, pas la décision de savoir quoi tester et pourquoi. Les outils d'IA aident à générer des scripts ou des cas de test, mais ils se trompent et demandent une relecture humaine. Le métier se déplace vers l'analyse et la stratégie, il ne disparaît pas.

Quel salaire espérer pour un QA Engineer ?

Les fourchettes varient beaucoup selon le pays, la taille de l'entreprise et le niveau d'automatisation demandé. Renseignez-vous sur les sources officielles et les grilles salariales à jour de votre marché avant de négocier. Les chiffres donnés dans un article vieillissent vite, vérifiez toujours la source actuelle.