Le rôle se décline en deux variantes : choisissez tôt

Quand la plupart des gens disent "ingénieur QA", ils désignent deux métiers distincts. Les testeurs QA manuels explorent le logiciel à la main, rédigent des cas de test, signalent des bugs, et communiquent leurs conclusions aux développeurs et aux chefs de produit. Les ingénieurs QA en automatisation écrivent du code qui teste le logiciel automatiquement, en lançant des vérifications à chaque déploiement sans qu'un humain clique sur quoi que ce soit.

Le QA manuel est plus facile à démarrer. L'automatisation est significativement mieux rémunérée et offre une meilleure trajectoire de carrière sur le long terme. Le salaire médian d'un ingénieur QA en automatisation aux États-Unis se situe entre 95 000 et 115 000 dollars selon la localisation et la taille de l'entreprise. Les postes QA manuels se situent généralement 20 000 à 30 000 dollars en dessous.

Ce guide couvre le chemin de l'automatisation, parce que c'est là que le marché se dirige et que la progression de carrière est la plus forte. Si vous partez de zéro, c'est la voie qui en vaut la peine.

Bonne nouvelle : aucun diplôme en informatique n'est nécessaire pour l'un ou l'autre de ces rôles. Des dizaines d'ingénieurs QA en automatisation en activité ont commencé comme enseignants, agents de service client, chefs de projet ou comptables. Les compétences techniques s'apprennent. Ce que vous vendez en entretien, c'est la preuve que vous les avez acquises.

Les seules compétences techniques qui comptent pour un premier poste

Les offres d'emploi pour des postes QA junior en automatisation en 2026 convergent vers la même courte liste. Si vous voyez une annonce qui demande 15 compétences spécifiques, la plupart sont aspirationnelles. Ce qui vous fait passer le test technique, c'est ceci :

Playwright (ou Selenium, mais Playwright est fortement préféré), TypeScript, tests d'API de base, Git, et une compréhension du fonctionnement du CI. La plupart des projets modernes utilisent TypeScript, pas JavaScript brut. C'est tout. Le reste s'apprend sur le tas.

Voici un exemple concret de ce que fait un ingénieur QA junior en automatisation le premier jour. Vous clonez un dépôt de tests, lancez la suite, regardez certains tests passer et quelques-uns échouer. Votre première tâche est de comprendre pourquoi certains échouent. Ça nécessite Git pour récupérer le code, Node.js pour l'exécuter, TypeScript pour le lire, et Playwright pour comprendre les erreurs. Rien d'autre. Aucune certification, aucune checklist de 30 compétences.

Vous verrez des annonces demandant Cypress, WebDriver, voire Katalon. Ces outils existent et sont utilisés. Mais Playwright est devenu le framework dominant pour les nouveaux projets en 2026, il est maintenu par Microsoft, et l'apprendre en premier ne ferme aucune porte.

Commencez par Playwright, avant tout le reste

C'est la partie contre-intuitive de la feuille de route. La plupart des gens commencent par "apprendre la programmation" parce que c'est ce que les guides de reconversion leur conseillent. Le problème avec cette approche : les exercices de programmation pure sont abstraits et deviennent vite ennuyeux. Vous passerez des semaines sur du fizzbuzz et de la manipulation de tableaux. La vraie raison pour laquelle vous vouliez apprendre, tester et casser des logiciels, reste indéfiniment dans le futur.

Commencez par Playwright. Acceptez que vous copierez-collerez du code que vous ne comprendrez pas entièrement. Exécutez-le. Regardez-le fonctionner. Cassez-le délibérément. Voyez quelle erreur revient.

Voici le premier test qui vaut vraiment la peine d'être écrit, sur lab.becomeqa.com :

import { test, expect } from '@playwright/test';

test('login with valid credentials', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('My Travel Items')).toBeVisible();
});

Lancez-le. Regardez-le ouvrir un navigateur, remplir des champs et cliquer sur des boutons sans que vous touchiez à quoi que ce soit. Cette sensation de voir l'automatisation fonctionner pour la première fois, c'est ce qui fait tenir à travers les parties difficiles.

Écrivez ensuite un deuxième test qui utilise des identifiants incorrects et vérifie que le message d'erreur apparaît. Puis un troisième qui se déconnecte et vérifie que la page revient à l'état de connexion. Trois tests, tous sur une vraie UI, et vous avez déjà pratiqué les locators, les assertions et la structure de test.

Quand Playwright ne trouve pas un élément, lancez npx playwright codegen https://lab.becomeqa.com. Un navigateur s'ouvre et génère le code de locator pendant que vous cliquez. Utilisez-le pour comprendre comment Playwright voit la page, puis écrivez vos propres locators à la main.

JavaScript et TypeScript : apprenez juste ce qu'il faut, puis continuez

Une fois que vous écrivez des tests, vous heurterez des murs liés au langage. Vous verrez async et await sans savoir ce que ça signifie. Vous voudrez stocker une valeur d'une étape de test et l'utiliser dans une autre sans savoir comment fonctionnent les variables à travers les appels await. C'est à ces moments-là qu'il faut s'arrêter et apprendre le concept de langage qui vous bloque.

Le minimum JavaScript/TypeScript avant d'écrire de vrais tests : les variables, les fonctions, les tableaux et les objets, async/await et pourquoi ça existe, et les opérations de base sur les chaînes. Ça représente environ deux à trois semaines de pratique quotidienne si vous n'avez jamais écrit de code.

Les concepts que vous assimilerez en écrivant davantage de tests : les types et interfaces TypeScript, la déstructuration, les modules et les imports, et les classes quand vous arriverez au Page Object Model.

Un exemple concret de comment async/await piège les débutants. Si vous écrivez ceci :

const text = page.getByText('Welcome').textContent();
console.log(text); // affiche une Promise, pas le texte

Vous obtenez un objet Promise affiché dans la console, pas le texte réel. La version correcte est :

const text = await page.getByText('Welcome').textContent();
console.log(text); // affiche 'Welcome'

await dit à JavaScript : arrête-toi ici, attends que cette opération asynchrone se termine, puis donne-moi le résultat. Chaque action Playwright utilise await. Comprendre pourquoi rend le débogage dix fois plus rapide.

Les tests d'API ne sont pas optionnels

La plupart des débutants sautent les tests d'API parce que ça semble être une compétence séparée et plus difficile. Ce n'est ni l'un ni l'autre. Un test d'API est simplement une requête HTTP avec des assertions sur la réponse. Pas de navigateur, pas de clic, pas de locators.

Voilà pourquoi ça doit figurer tôt dans votre liste d'apprentissage : les tests d'API sont cinq à dix fois plus rapides que les tests UI et ils échouent pour moins de raisons sans rapport. Un test UI peut échouer parce qu'un bouton a bougé, qu'un spinner de chargement a pris une seconde de plus, ou qu'une infobulle a recouvert l'élément. Un test d'API échoue parce que les données sont incorrectes, ce qui est la chose qui vous intéresse réellement.

Playwright intègre les tests d'API dans le même framework que vous utilisez déjà :

test('GET /api/items returns travel items', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

  expect(response.status()).toBe(200);

  const body = await response.json();
  expect(body.length).toBeGreaterThan(0);
  expect(body[0]).toHaveProperty('destination');
  expect(body[0]).toHaveProperty('id');
});

Pas de nouveaux outils. Pas de framework séparé. Les mêmes fonctions test et expect que vous connaissez déjà, avec request à la place de page.

Passez aussi quelques heures dans Postman. Pas parce que vous l'utiliserez pour l'automatisation, mais parce qu'explorer manuellement une API avant d'en écrire les tests fait gagner du temps. Vous envoyez des requêtes, vous voyez les structures de réponse, vous comprenez les headers d'authentification. Votre code de test a du sens plutôt que d'être copié aveuglément depuis la documentation.

Construisez quelque chose à montrer, pas seulement quelque chose à comprendre

C'est là que la plupart des autodidactes se bloquent. Ils suivent des tutoriels, font des exercices, et ont l'impression de progresser. Puis quelqu'un demande "puis-je voir votre travail ?" et il n'y a rien à montrer.

Les recruteurs regardent les profils GitHub pour les candidats QA junior. Pas parce qu'ils attendent des suites de tests au niveau senior. Parce qu'un dépôt GitHub prouve que vous avez réellement écrit le code et que vous n'avez pas seulement regardé des vidéos à ce sujet.

Un portfolio qui vous vaudra des entretiens est simple : un dépôt GitHub avec une suite Playwright en TypeScript et un Page Object Model pour au moins deux pages. Ajoutez des tests UI et API, plus un workflow GitHub Actions qui lance les tests à chaque push. C'est tout. C'est la barre.

La partie Page Object Model semble intimidante avant de l'avoir faite. Le concept : plutôt que d'écrire page.getByLabel('Username').fill(username) dans chaque test qui doit se connecter, vous créez une classe LoginPage avec une méthode login(username, password). Les tests appellent loginPage.login('admin@becomeqa.com', 'testpass123'). Si le formulaire de connexion change un jour, vous le corrigez à un seul endroit.

// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  async login(username: string, password: string) {
    await this.page.getByRole('button', { name: 'Login' }).click();
    await this.page.getByLabel('Username').fill(username);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Submit' }).click();
  }
}

Utilisez lab.becomeqa.com comme site à automatiser pour votre portfolio. Le site a suffisamment de complexité pour démontrer de vraies compétences : connexion, tableaux de données, modales, upload de fichier, endpoints API. Il ne risque pas de tomber ni de bloquer le trafic automatisé.

Comment appliquer ça dès lundi matin

Si vous lisez ça un dimanche soir et que vous voulez un plan concret pour la semaine à venir, le voici.

Lundi : Installez Node.js et Playwright. Suivez le quickstart officiel. Faites tourner un test contre lab.becomeqa.com. N'avancez pas avant de voir un test vert dans votre terminal. Mardi : Écrivez cinq tests supplémentaires. Connexion réussie, connexion échouée, navigation vers une section spécifique, vérification que les données se chargent, et un qui utilise l'endpoint API directement. Vous rencontrerez des problèmes. C'est ça, la vraie pratique. Mercredi : Apprenez le concept async/await correctement. Lisez l'article MDN sur les Promises. Regardez une courte vidéo. Revenez lire votre code de test existant. Il devrait avoir plus de sens. Jeudi : Créez un compte GitHub si vous n'en avez pas. Poussez votre dépôt de tests. Faites un README honnête : "Apprentissage de Playwright, travail en cours" convient parfaitement. Vendredi : Ajoutez un fichier de workflow GitHub Actions. La documentation Playwright a un exemple à copier-coller pour ça. Faites tourner vos tests dans GitHub Actions. Prenez une capture d'écran du check vert. Gardez-la.

Deuxième semaine : Page Object Model pour le flux de connexion. Troisième semaine, les interfaces TypeScript pour vos données de réponse API. Quatrième semaine, postulez à un poste QA junior même si vous ne vous sentez pas prêt. Lire l'offre d'emploi vous dira exactement quoi étudier ensuite.

Les gens qui sont embauchés n'attendent pas de se sentir prêts. Ils construisent la preuve qu'ils peuvent faire le travail, la mettent quelque part de visible, et commencent à contacter des entreprises pendant qu'ils continuent d'apprendre.

FAQ

Combien de temps faut-il réalistement pour être embauché ?

Quatre à six mois de pratique quotidienne pour la plupart des personnes sans expérience préalable en programmation. Moins si vous venez d'un milieu développement. Plus si vous ne pratiquez que le week-end. La variable n'est pas le talent. C'est la régularité et la qualité de ce que vous construisez pour le montrer.

Dois-je connaître Selenium ?

Pas pour être embauché dans la plupart des entreprises aujourd'hui. Playwright a supplanté Selenium sur la majorité des nouveaux projets. Si une entreprise spécifique que vous voulez rejoindre utilise Selenium, vous pouvez apprendre les différences en une semaine une fois que vous connaissez Playwright. Les concepts sont quasi identiques, la syntaxe diffère.

Y a-t-il une certification qui vaut la peine ?

L'ISTQB Foundation Level est la certification la plus reconnue en QA. Elle démontre une familiarité avec la théorie et la terminologie du test. Certaines entreprises la filtrent, la plupart ne l'exigent pas. Si vous choisissez entre obtenir la certification ISTQB et construire un projet de portfolio, construisez le projet de portfolio. Un dépôt GitHub avec des tests qui fonctionnent est une preuve plus concrète qu'un examen à choix multiples.

Que dois-je mettre dans mon CV si je n'ai aucune expérience QA professionnelle ?

Votre portfolio GitHub, précisément. Listez le projet avec un lien et indiquez les technologies. Décrivez ce que vous avez construit : "Suite de tests Playwright avec 40+ tests couvrant des flux UI et des endpoints REST API, lancés en CI via GitHub Actions". Les recruteurs voient les liens GitHub et les suivent réellement. Mettez votre CV devant des personnes qui cliqueront sur le lien avant de vous inquiéter de la formulation du reste.

Manuel ou automatisation en premier ?

Automatisation. C'est mieux rémunéré, c'est là que va l'industrie, et la courbe d'apprentissage est concentrée au début. Une fois passée, vous êtes employable. Commencer par le QA manuel et passer à l'automatisation plus tard signifie apprendre deux fois. La seule exception : si vous pouvez obtenir rapidement un poste QA manuel et l'utiliser pour transitionner en interne dans une entreprise qui financera votre temps de développement.

→ See also: Le Plan de 90 Jours pour Décrocher Votre Premier Emploi QA | Comment Construire un Portfolio QA qui Vous Fait Recruter (GitHub + Playwright) | Parcours Professionnel QA: De Junior à Ingénieur QA Senior