Le Plan de 90 Jours pour Décrocher Votre Premier Emploi QA

Ce plan de 90 jours découpe semaine par semaine le chemin de zéro à un premier poste junior en automatisation QA. Trois mois, trois phases. Le premier mois pose les fondamentaux du test manuel et vos premiers tests Playwright. Le deuxième cible 20 tests automatisés sur un site d'entraînement. Le troisième met en forme le portfolio et lance les premières candidatures. À raison d'une heure par jour en semaine et deux à trois heures le week-end, vous terminez avec un portfolio réel et des candidatures actives.

Jours 1 à 30 : Les fondations

L'objectif du premier mois n'est pas de devenir expert. C'est de vous sentir à l'aise avec le vocabulaire et l'état d'esprit QA. C'est aussi de comprendre à quoi ressemblent les cas de test et les rapports de bugs dans une vraie équipe, et d'écrire votre premier test Playwright fonctionnel. Vous ferez tout ça en parallèle. Concepts de test manuel les deux premières semaines, automatisation à partir de la semaine trois. À J30, vous aurez touché à tout ce sur quoi vous allez construire la suite.

Semaine 1 : Fondamentaux du test manuel

Consacrez la première semaine à comprendre à quoi ressemble un test structuré. Le livrable clé du travail de QA manuel est le cas de test : un ensemble documenté d'étapes, de préconditions, de résultats attendus et de résultats réels. Écrivez cinq cas de test pour le flux de connexion sur lab.becomeqa.com, à la main, dans un Google Sheet ou un doc Notion. Utilisez des colonnes pour l'ID du cas de test, la précondition, les étapes, le résultat attendu, le résultat réel, et le statut.

Ne rendez pas les étapes vagues. Un bon cas de test ressemble à ça : "Aller sur la page de connexion, saisir l'email admin@becomeqa.com, entrer un mauvais mot de passe, cliquer sur Submit, vérifier que le message d'erreur indique 'Invalid credentials'." "Vérifier que la connexion fonctionne" n'en est pas un. La précision est la compétence en entier.

Une fois les cas de test de connexion écrits, rédigez-en cinq autres pour la liste d'éléments. Vérifier que les éléments se chargent et que le nombre correspond à ce que l'API renvoie. Vérifier que le tri fonctionne, que la recherche filtre les résultats, et qu'une recherche vide affiche un état vide significatif. Exécutez chacun manuellement et consignez les bugs trouvés.

Quand vous trouvez un bug (et vous en trouverez), rédigez-le comme un rapport de bug formel. Un rapport de bug minimal comporte un titre, l'environnement (navigateur, OS), les préconditions, les étapes de reproduction, le comportement attendu, le comportement réel, et la sévérité. La sévérité ne dépend pas de votre niveau d'agacement. Critique signifie que l'application est cassée pour tous les utilisateurs. Majeure signifie qu'une fonctionnalité clé ne fonctionne pas. Mineure signifie que quelque chose semble incorrect sans bloquer quoi que ce soit. Triviale signifie une faute de frappe.

Semaine 2 : Bases Agile et posture QA dans une équipe

Le vrai travail de QA se passe dans des sprints Agile. Passez cette semaine à comprendre comment les ingénieurs QA s'insèrent dans ce processus. Vous devez comprendre ce qu'est une user story et comment les critères d'acceptation se rapportent aux cas de test. Vous devez savoir ce que signifie la "definition of done" et pourquoi le QA en fait partie. Et à quoi ressemble une sprint review du point de vue QA.

L'exercice pratique : prenez trois user stories d'un tableau de gestion de projet public et rédigez des critères d'acceptation pour chacune. Les modèles Trello fonctionnent, ou écrivez les vôtres à partir des fonctionnalités de lab.becomeqa.com. Convertissez ensuite ces critères en cas de test. C'est le flux réel dans un vrai poste. La story arrive, vous écrivez les tests avant que le développement soit terminé, puis vous vérifiez quand le développeur dit que c'est prêt.

Lisez sur la différence entre vérification (a-t-on construit la chose correctement ?) et validation (a-t-on construit la bonne chose ?). Ces termes reviennent en entretien.

Semaines 3 et 4 : Débuter avec Playwright

Installez Node.js (version LTS) et créez un nouveau projet Playwright avec npm init playwright@latest. Choisissez TypeScript quand on vous le demande. Playwright crée une structure de dossiers et un test d'exemple. Lancez npx playwright test et regardez-le passer. Cette structure (tests/, playwright.config.ts, package.json) est ce sur quoi vous allez construire pendant deux mois.

Votre premier test à écrire de zéro est un test de connexion contre lab.becomeqa.com :

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

test('connexion avec des identifiants valides affiche le tableau de bord', 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 avec npx playwright test --headed pour voir le navigateur s'ouvrir et remplir les champs tout seul. C'est le moment qui accroche la plupart des gens. Écrivez ensuite deux tests supplémentaires : un pour des identifiants invalides (vérifiez que le message d'erreur apparaît), un pour la déconnexion (vérifiez que le bouton de connexion est à nouveau visible). À la fin de la semaine 4, vous devriez avoir six à huit tests qui passent et une vraie intuition de comment Playwright pense les pages.

Jours 31 à 60 : Compétences en automatisation

Le deuxième mois est là où le vrai travail se fait. Vous allez approfondir Playwright, apprendre les stratégies de locateurs, écrire des assertions avec assurance, et implémenter le Page Object Model. Vous allez aussi vous familiariser avec Git et GitHub et atteindre un objectif concret : 20 tests ou plus sur lab.becomeqa.com. C'est le matériau que les intervieweurs techniques vont tester.

Semaine 5 : Locateurs et assertions

Playwright vous donne plusieurs façons de trouver des éléments sur une page. La bonne hiérarchie, du plus au moins préféré : getByRole, getByLabel, getByPlaceholder, getByText, getByTestId, puis les sélecteurs CSS en dernier recours. La raison de cet ordre est la résilience. Les locateurs basés sur les rôles et les labels survivent quand un développeur renomme une classe CSS ou change un div en section. Les sélecteurs CSS, non.

Passez la semaine 5 à écrire des locateurs pour chaque élément majeur de lab.becomeqa.com avec les méthodes préférées. Utilisez npx playwright codegen https://lab.becomeqa.com pour voir comment Playwright identifie les éléments pendant que vous cliquez. Réécrivez ensuite à la main chaque locateur généré dans le format préféré. C'est un exercice de pratique délibérée. Le codegen produit souvent des sélecteurs CSS, et vous voulez construire l'habitude de choisir de meilleures options.

Pour les assertions, pratiquez les variantes "soft" et "hard". Une assertion dure (expect(locator).toBeVisible()) arrête le test immédiatement si elle échoue. Une assertion douce (expect.soft(locator).toBeVisible()) enregistre l'échec mais continue le test pour détecter d'autres problèmes en un seul passage. Utilisez les assertions douces quand vous voulez vérifier l'état d'une page entière en une fois. Utilisez les assertions dures quand un échec signifie que rien d'autre dans le test ne peut être fiable.

Semaine 6 : Page Object Model

À ce stade, vos tests sont probablement répétitifs. Chaque test qui nécessite un utilisateur connecté répète les mêmes quatre lignes. Le Page Object Model (POM) élimine cette duplication et rend vos tests lisibles comme de la documentation.

Créez un dossier pages/. Commencez avec deux fichiers : LoginPage.ts et ItemsPage.ts.

// pages/LoginPage.ts
import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async navigate() {
    await this.page.goto('https://lab.becomeqa.com');
  }

  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();
  }

  async getErrorMessage() {
    return this.page.getByRole('alert').textContent();
  }
}

// pages/ItemsPage.ts
import { Page, Locator } from '@playwright/test';

export class ItemsPage {
  readonly itemRows: Locator;

  constructor(private page: Page) {
    this.itemRows = this.page.getByRole('row');
  }

  async getItemCount() {
    return this.itemRows.count();
  }

  async searchFor(term: string) {
    await this.page.getByPlaceholder('Search').fill(term);
  }
}

Réécrivez tous vos tests existants pour utiliser ces classes. Un test qui faisait douze lignes de setup en fait quatre. Plus important : si le libellé du bouton de connexion change demain, vous le corrigez dans un seul fichier au lieu de vingt.

Semaine 7 : Git et GitHub

Vous écrivez du code depuis un mois. Il faut maintenant le versionner correctement et le mettre quelque part de visible. Installez Git si ce n'est pas fait. Créez un compte GitHub. Publiez votre projet Playwright comme dépôt public.

Le flux Git dont vous avez besoin pour un poste : git status pour voir ce qui a changé, git add pour préparer des fichiers spécifiques, git commit -m "message" pour sauvegarder un snapshot, git push pour uploader. À ce stade vous travaillez seul, donc pas encore besoin des workflows de branches. Pratiquez quand même. Créez une branche avec git checkout -b add-items-tests, écrivez vos tests là, commitez-les, et fusionnez avec git checkout main && git merge add-items-tests. C'est ainsi que fonctionne chaque équipe dans laquelle vous travaillerez.

Écrivez un README pour votre dépôt. Pas besoin qu'il soit long. Dites aux lecteurs ce qu'est le projet, comment installer les dépendances (npm install), comment lancer les tests (npx playwright test), et quel site vous testez. Un README qui existe et dont les instructions fonctionnent vaut déjà mieux que la plupart des portfolios juniors.

Semaine 8 : 20 tests et couverture API

C'est la semaine d'exécution. Votre objectif est d'atteindre 20 tests ou plus sur lab.becomeqa.com. Ça paraît beaucoup. Ce n'est pas le cas. Entre les flux de connexion, les opérations CRUD sur les éléments, la recherche, le filtrage, et les endpoints API, il y a facilement 40 scénarios à tester.

Pour les tests API, Playwright les intègre nativement. Pas d'outil séparé nécessaire :

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

test('GET /api/items retourne une liste avec les champs requis', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

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

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

Écrivez au moins cinq tests API. Un GET happy-path, un POST qui crée un élément, et un DELETE qui le supprime. Plus un test d'authentification (que se passe-t-il si vous appelez l'API sans token ?). Et un qui valide que la structure de la réponse correspond à ce qu'affiche l'interface. Mélangez vos tests API et UI dans la même suite. C'est ainsi que les vrais projets sont structurés.

Jours 61 à 90 : Portfolio et recherche d'emploi

Le troisième mois consiste à convertir tout ce que vous avez construit en quelque chose qui vous fait embaucher. Vous allez configurer la CI pour que vos tests tournent automatiquement, rédiger un README professionnel, soigner votre profil LinkedIn, et commencer à postuler. La recherche d'emploi et l'apprentissage se font en parallèle. N'attendez pas le jour 90 pour envoyer votre première candidature.

Semaine 9 : GitHub Actions CI

Une suite de tests qui tourne uniquement sur votre ordinateur vaut moins pour un recruteur qu'une suite qui tourne dans le cloud à chaque commit. Configurez GitHub Actions en créant un fichier .github/workflows/playwright.yml :

name: Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Poussez ce fichier. Regardez l'onglet Actions dans votre dépôt GitHub. Un workflow se déclenche et vos tests tournent dans un conteneur Linux. Quand ils passent, une coche verte apparaît à côté de votre dernier commit. Cette coche verte, vous pouvez la mettre en capture d'écran sur LinkedIn. C'est aussi une preuve concrète que vous comprenez la CI, un sujet qui revient dans presque tous les entretiens techniques.

Si certains tests sont flaky en CI (ils passent en local mais échouent de façon intermittente dans le pipeline), c'est en soi une leçon importante. Les tests flaky échouent généralement en CI à cause du timing : la page se charge plus lentement sur une machine cloud que sur votre laptop. Remplacez les attentes fixes (page.waitForTimeout(2000)) par de vraies attentes Playwright (page.waitForSelector, ou faites simplement confiance à l'auto-wait des assertions). Cherchez et corrigez chaque test flaky. Un run CI avec un test rouge flaky est pire qu'un run CI avec 15 tests au lieu de 20.

Semaine 10 : Soigner le portfolio

Votre dépôt GitHub a besoin de trois choses avant de commencer à postuler : un nombre de tests valable à mentionner (20+), un badge CI dans le README, et une documentation qu'un inconnu peut suivre.

Ajoutez un badge CI à votre README en copiant l'URL du badge depuis votre workflow GitHub Actions. Ça ressemble à ça en Markdown :

![Playwright Tests](https://github.com/VOTRE_NOM/VOTRE_REPO/actions/workflows/playwright.yml/badge.svg)

Quand les tests passent, ce badge s'affiche en vert dans votre README. C'est un détail qui montre que vous tenez aux pratiques professionnelles.

Développez votre README pour inclure une description du projet et ce que vous testez. Lab.becomeqa.com est une application d'entraînement pour ingénieurs QA. Ajoutez un tableau listant chaque fichier de test et ce qu'il couvre. Et expliquez comment lancer des groupes de tests spécifiques avec npx playwright test --grep @api. Ajoutez des tags comme @api et @ui à vos tests pour activer ça. L'objectif : quelqu'un qui n'a jamais vu votre projet peut le cloner, le lancer, et comprendre ce qu'il regarde en moins de dix minutes.

Semaine 11 : LinkedIn et CV

Votre profil LinkedIn a besoin de quatre choses pour attirer l'attention des recruteurs QA. Un titre qui dit ce que vous visez, par exemple "QA Automation Engineer | Playwright | TypeScript". Une section À propos de 3 à 4 phrases qui explique votre transition vers le QA et ce que vous avez construit. Une section En vedette avec un lien vers votre dépôt GitHub. Et une section Compétences listant Playwright, TypeScript, JavaScript, Git, GitHub Actions, Tests API, et Agile.

Si vous venez d'un autre domaine, ne le cachez pas. Présentez-le comme un atout. Dites quelque chose comme : "Mon background en relation client m'a donné un regard différent sur la façon dont les vrais utilisateurs interagissent avec les logiciels." C'est plus intéressant que de prétendre avoir toujours travaillé dans la tech.

Pour votre CV, listez le projet de portfolio GitHub comme une entrée d'expérience, pas comme une note de bas de page. Rédigez-le comme ceci : "Framework d'automatisation Playwright (Projet personnel). Suite de tests avec 25+ tests UI et API contre une application web en production, TypeScript et Playwright. Pipeline CI/CD configuré avec GitHub Actions. Page Object Model implémenté pour la maintenabilité." Chaque mot est vrai, précis, et correspond directement à ce que les offres d'emploi demandent.

Sans expérience QA professionnelle, votre CV comporte deux sections : le projet portfolio et vos expériences professionnelles précédentes. Présentez ces dernières sous l'angle des compétences transférables (attention aux détails, rigueur de processus, communication, travail technique si pertinent). Tenez-le en une page.

Semaine 12 : Postuler et continuer

Commencez à postuler avant de vous sentir prêt. Vous ne vous sentiez pas prêt au jour 30, ni au jour 60, et vous ne vous sentirez pas prêt au jour 90. La façon de savoir quelles lacunes vous avez est d'entrer dans des entretiens et de voir ce qu'on vous demande. Un refus après un écran technique où vous ne pouviez pas répondre à une question sur les fixtures ou la gestion des données de test vous dit exactement quoi étudier ensuite. C'est précieux.

Postulez à 5 à 10 entreprises en semaine 12. Priorisez les entreprises avec de petites équipes QA, où vous apprendrez plus et aurez plus d'autonomie. Priorisez aussi les entreprises dont vous utilisez réellement les produits, l'intérêt sincère se voit en entretien. Et celles qui recrutent explicitement des ingénieurs junior en automatisation, pas juste des rôles "analyste QA" purement manuels.

Après chaque entretien, notez chaque question à laquelle vous n'avez pas pu répondre. Passez une heure sur chaque sujet le lendemain. Vous vous débrouillerez mieux au deuxième entretien qu'au premier, et mieux au troisième qu'au deuxième.

FAQ

Vingt est le minimum. Trente à quarante, c'est solide. Pas besoin de plus. Le but est de montrer de la largeur (tests UI, tests API, POM, CI), pas du volume. Cinq tests couvrant la connexion, la liste d'éléments, un endpoint API, et montrant le Page Object Model sont plus impressionnants que cinquante tests de connexion copiés-collés.

La plupart des projets Playwright modernes utilisent TypeScript. Vous n'avez pas besoin d'être expert en TypeScript. Le typage statique aide plus qu'il ne gêne. Commencez avec TypeScript dès le premier jour, laissez votre éditeur vous dire quand les types sont faux, et cherchez ce que l'erreur signifie. C'est 90% de la façon dont on l'apprend.

Si votre volume de candidatures est inférieur à 30 et que vous postulez depuis moins de quatre semaines, il est trop tôt pour tirer des conclusions. Au-delà de 30 candidatures sans réponse, le problème vient généralement du CV ou du profil LinkedIn, pas de vos compétences. Faites relire votre CV par quelqu'un dans un rôle QA ou tech. Rejoignez les communautés QA sur LinkedIn et Discord. Les gens dans ces communautés partagent souvent des postes ouverts et peuvent vous recommander en interne, ce qui court-circuite entièrement la pile de CV.

Jamais à la place du portfolio. Si vous avez du temps libre en mois un pendant que les concepts techniques sont encore légers, lire le programme de la fondation ISTQB est utile pour le vocabulaire. Mais un portfolio GitHub fonctionnel avec CI est une preuve plus solide de vos capacités que n'importe quelle certification. Les recruteurs qui vous disent le contraire sont minoritaires.

Continuer à postuler et à construire. Ajoutez un second projet de portfolio. Écrivez des tests sur une autre application. Beaucoup de projets open source acceptent des contributions qui incluent des tests, ce qui vous donne une vraie expérience collaborative. Commencez un blog technique simple documentant ce que vous avez appris. Même deux ou trois articles sur des problèmes spécifiques que vous avez résolus montrent que vous savez communiquer des idées techniques. Le plan de 90 jours vous amène à la ligne de départ, pas à la ligne d'arrivée. La plupart des gens obtiennent leur première offre QA entre le mois 4 et le mois 6.