Roadmap d'Automatisation QA 2026: Les Compétences Essentielles pour Être Recruté

Chaque compétence ouvre la suivante. L'ordre reflète ce que les offres d'emploi junior testent réellement en entretien technique.

Pourquoi l'ordre compte

Sans JavaScript, vous ne pouvez pas écrire de vrais tests. Point. Et vous ne pouvez pas automatiser une API si personne ne vous a encore expliqué ce qu'est une API. Vous ne pouvez certainement pas configurer CI/CD quand vous n'avez pas encore un seul test qui vaille d'être lancé.

Chaque compétence ici déverrouille la suivante. Sautez dans tous les sens et vous passerez deux fois plus de temps à être perdu.

1. Playwright : votre framework d'automatisation

Selenium était la réponse. Plus maintenant. Pas pour ceux qui commencent à apprendre en 2026.

Playwright a pris sa place sur la plupart des nouveaux projets, et les raisons deviennent évidentes dès que vous utilisez les deux. Il attend automatiquement les éléments au lieu de vous faire deviner des délais. Il vient avec un test runner intégré, des enregistrements vidéo des échecs, l'interception réseau et un générateur de code qui écrit des locateurs pendant que vous cliquez sur la page.

Voici à quoi ressemble un vrai test Playwright :

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

test('utilisateur peut se connecter', 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();
});

Propre. Pas de boilerplate. Si rien de tout ça n'a de sens pour l'instant, c'est normal. Le cours Playwright couvre exactement ça.

2. JavaScript/TypeScript : la couche langage

Certains essaient de sauter cette étape et de passer directement aux tests. Ça tient peut-être deux semaines. Ensuite quelque chose casse et ils n'ont aucune idée du pourquoi, parce qu'ils n'ont jamais appris le langage, ils ont juste copié-collé.

Playwright, c'est JavaScript. TypeScript, c'est JavaScript avec des types. Les types attrapent vos erreurs avant l'exécution. Playwright génère du TypeScript par défaut et après une semaine avec lui, vous n'aurez pas envie de revenir au JS pur.

Ce dont vous avez vraiment besoin :

Commencez par les variables, les types de données, les fonctions, les tableaux et objets, et async/await. Ce dernier point n'est pas optionnel. Chaque action Playwright l'utilise. Sans comprendre async/await, vous avancez à l'aveugle.

Ensuite, quand vous écrivez des tests régulièrement : la déstructuration, le spread operator, les modules, la gestion d'erreurs avec try/catch, et les classes pour le Page Object Model.

N'attendez pas d'avoir "fini JavaScript" avant de toucher aux tests. C'est un piège. Apprenez l'essentiel, commencez à écrire des tests, complétez au fur et à mesure. Les tests vous donnent une raison concrète d'utiliser le langage.

3. Pratiquer sur un vrai site

La théorie sans site à automatiser, c'est juste de la lecture. Il vous faut de vrais formulaires, de vraies tables, de vrais cas limites.

La plupart des sites d'entraînement sont soit trivialement simples (un bouton, un champ) soit ils tombent aléatoirement et produisent des erreurs sans rapport avec votre code de test. Les deux sont pires qu'inutiles pour apprendre.

Nous avons créé lab.becomeqa.com pour ça. Flux de connexion complet, tables de données triables, modales, upload de fichiers, formulaire de paiement branché sur le mode test de Stripe, et endpoints d'API exposés pour les tests directs. Le site est maintenu stable parce qu'un environnement d'entraînement flaky vous enseigne de mauvaises habitudes de débogage.

D'autres options valables : SauceDemo, The Internet de Dave Haefner, TodoMVC. Mais lab.becomeqa.com a l'API configurée pour correspondre aux exercices de ce cours.

4. Tests d'API : plus rapides et plus stables que les tests UI

La plupart des débutants ne le savent pas : la majorité des bugs dans les applications web ne se trouve pas dans l'interface. Ils se trouvent dans l'API, la logique backend que l'interface appelle.

Les tests UI prennent des secondes. Les tests d'API prennent des millisecondes. Et les tests d'API ne tombent pas parce qu'un bouton a bougé de deux pixels ou qu'un spinner de chargement a pris un peu plus de temps que prévu. Ils sont plus stables, plus rapides à écrire, et attrapent une catégorie de bugs que les tests UI n'atteignent tout simplement jamais.

Playwright intègre les tests d'API via la fixture request :

test('GET /api/items retourne une liste', 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('destination');
});

Pas de navigateur. Pas de page. Juste HTTP. Les outils à connaître : la fixture request (déjà intégrée dans Playwright), Postman pour l'exploration manuelle des API, et les méthodes HTTP de base (couvertes dans la compétence 7).

5. CI/CD : rendre vos tests vraiment utiles

Des tests qui ne tournent que sur votre ordinateur ne détectent pas les bugs en production. Ils les détectent quand vous pensez à les lancer manuellement. Ce n'est pas de l'automatisation, c'est du test manuel différé.

Les pipelines CI/CD lancent vos tests à chaque commit, chaque PR, chaque déploiement. Automatiquement. Voici comment les principaux outils diffèrent en pratique :

Intégrez vos tests Playwright dans GitHub Actions d'abord. C'est faisable en une journée.

6. Bases SQL : vérifiez la base de données vous-même

À un moment, vous devrez vérifier que ce que montre l'interface a bien été enregistré en base. Ou consulter des données que l'interface n'expose jamais. Pour ça, il faut SQL.

Bonne nouvelle : le SQL pour QA n'est pas du SQL complexe. C'est environ cinq patterns de requêtes qui couvrent 80% de ce dont vous aurez besoin :

-- Vérifier qu'un utilisateur existe
SELECT * FROM users WHERE email = 'test@example.com';

-- Vérifier des données liées entre tables
SELECT orders.id, users.email, orders.status
FROM orders
JOIN users ON orders.user_id = users.id
WHERE orders.status = 'pending';

Deux SELECT. Un JOIN. Des conditions WHERE. C'est vraiment la quasi-totalité. Les postes qui demandent une "expérience SQL" demandent presque toujours exactement ça, et guère plus.

7. Comment fonctionne internet

Chaque test que vous écrivez envoie des requêtes sur un réseau. Comprendre ce qui se passe en dessous vous aide à lire les messages d'erreur correctement et à identifier ce qui a cassé. Vous suivez aussi plus facilement ce que les développeurs décrivent quand quelque chose ne va pas.

Tapez https://lab.becomeqa.com dans un navigateur et quatre choses se produisent en séquence :

• Résolution DNS. Le navigateur demande : "quelle est l'IP de lab.becomeqa.com ?" Il reçoit quelque chose comme 104.21.8.42. Les noms de domaine sont des alias.
• Connexion TCP. Le navigateur se connecte à cette IP sur le port 443, le port HTTPS standard.
• Handshake TLS. Le navigateur et le serveur vérifient leurs identités et négocient le chiffrement. C'est le S de HTTPS.
• Requête/réponse HTTP. Le navigateur envoie GET / HTTP/1.1, le serveur renvoie du HTML.

Moins de 100 ms sur une connexion correcte.

"Connection refused" est un problème différent de "SSL certificate error", qui est différent de "404 Not Found". Trois points distincts dans cette chaîne. Sans connaître la chaîne, chaque erreur réseau vous paraît identique et le débogage prend cinq fois plus de temps.

Bases HTTP : les requêtes ont une méthode (GET lit, POST crée, PUT/PATCH met à jour, DELETE supprime), un chemin, des en-têtes et optionnellement un corps. Les réponses ont des codes de statut (200 c'est bon, 404 le chemin n'existe pas, 500 le serveur lui-même a planté). Chaque clic et soumission de formulaire dans un test Playwright est une de ces requêtes en coulisse.

8. Bases Git

Git, c'est comment le code de test est partagé, versionné et déployé. Vous l'utilisez pour stocker vos tests, rester synchronisé avec les développeurs et déclencher les runs CI. Inutile de comprendre les entrailles de Git. Six commandes et un fichier de configuration, c'est tout.

git clone <repo-url>            # télécharger le projet sur votre machine
git pull                        # récupérer les dernières modifications de l'équipe
git checkout -b add-login-tests # créer une branche pour vos nouveaux tests
git add tests/login.spec.ts     # préparer le fichier modifié pour le commit
git commit -m "add login tests" # sauvegarder un snapshot avec un message
git push origin add-login-tests # envoyer votre branche sur GitHub/GitLab

Clonez une fois. Faites un pull avant de commencer chaque jour. Une branche par tâche. Push quand c'est prêt. C'est la boucle.

Playwright génère des dossiers pleins de captures d'écran, vidéos et rapports HTML quand les tests tournent. Rien de tout ça n'a sa place dans le dépôt. Créez .gitignore à la racine du projet :

node_modules/
playwright-report/
test-results/
.env

Oubliez ce fichier et vous enverrez des centaines de mégaoctets d'artefacts. Vos coéquipiers sauront qui l'a fait.

Les tests passent en local mais échouent dans GitHub Actions. Très courant. La première chose à vérifier :

git log --oneline -5     # voir les 5 derniers commits
git diff main            # voir ce qui a changé par rapport à la branche principale

C'est généralement soit un fichier oublié dans le git add, soit une version de dépendance qui diffère entre votre machine et l'environnement CI. Git log montre exactement ce qui a été commité et ce qui ne l'a pas été.

9. Agile/Scrum : parler le langage de l'équipe

La compétence la plus simple de la liste. La plus sous-estimée par ceux qui changent de carrière. Vous n'avez pas besoin d'une certification. Vous avez besoin de ne pas avoir l'air perdu lors de votre propre standup.

Ce qui compte vraiment : un sprint, comment se déroulent les standups, la notion de user story, et ce que signifie "definition of done" côté QA. Ce dernier concept diffère de ce qu'entend un développeur.

La plupart des équipes utilisent Jira. L'outil change d'une entreprise à l'autre. Les concepts, non.

Combien de temps ça prend vraiment

Réponse honnête : quatre à six mois à raison d'une à deux heures par jour amènent la plupart des gens au niveau suffisant pour un premier poste. À condition de pratiquer vraiment, pas juste de lire.

Ceux qui mettent plus longtemps suivent presque toujours le même schéma : deux semaines de pratique intense, puis rien pendant six semaines. La régularité bat l'intensité. Une heure ennuyeuse chaque jour vaut mieux qu'un week-end héroïque par mois.

FAQ

Non. La plupart des ingénieurs QA automation n'en ont pas. Ce qui fait décrocher un poste, c'est un dépôt GitHub avec des tests bien écrits et la capacité d'expliquer ce qu'ils font. Un diplôme ne prouve pas ça. Les tests, oui.

Playwright pour tous ceux qui commencent de zéro en 2026. Si vous rejoignez une entreprise qui utilise déjà Selenium, apprenez leur setup. Pour un apprentissage nouveau, Playwright se prend en main plus vite, est mieux documenté et est maintenu par une équipe qui s'y intéresse vraiment.

Abordable. Vous ne construisez pas des applications. Vous lisez et écrivez des tests. C'est une tranche étroite du langage. La plupart des gens sont suffisamment à l'aise en quatre à six semaines de pratique quotidienne.

lab.becomeqa.com, un dépôt GitHub avec vos fichiers de tests, automatiser des parcours sur des sites publics. Un portfolio que vous pouvez présenter en partage d'écran lors d'un entretien vaut plus que n'importe quelle certification existante.