Comment Construire un Portfolio QA qui Vous Fait Recruter (GitHub + Playwright)

Un portfolio QA automation doit montrer du code fonctionnel contre une vraie application, pas seulement des descriptions de travaux passés.

Pourquoi un portfolio compte pour les postes QA

L'automatisation QA est une compétence technique. Les entreprises qui recrutent dessus veulent voir du code, pas des descriptions de code.

Un CV qui dit "5 ans d'expérience avec Playwright et TypeScript" et un portfolio qui montre cette expérience produisent des résultats différents à l'étape de présélection.

L'ingénieur recruteur qui examine votre candidature dispose de 30 à 60 secondes avant de décider de lire plus loin ou de passer. Un lien vers un dépôt GitHub avec du code de test propre et bien structuré fait plus de travail en ces 30 secondes qu'un paragraphe de texte.

La barrière est plus basse qu'elle ne semble. La plupart des ingénieurs QA n'ont pas de portfolio public. En avoir un vous place immédiatement dans une catégorie différente.

Quoi mettre dans un portfolio QA

Vous n'avez pas besoin d'un projet massif. Vous avez besoin de preuves de compétences spécifiques. Chaque élément de votre portfolio doit démontrer quelque chose de concret.

Une suite de tests Playwright contre une vraie application

C'est la pièce centrale. Un dépôt avec des tests pour une vraie application : pas une application de tutoriel, pas localhost, mais un site web vraiment accessible publiquement.

Quoi tester : l'environnement lab de BecomeQA sur lab.becomeqa.com existe spécifiquement pour ça. C'est une application React avec login, opérations CRUD, upload de fichiers et une section paiement. Écrivez des tests contre elle.

Ce que la suite doit inclure :

• Flux de connexion (chemin nominal + cas négatifs)
• Opérations CRUD pour la fonctionnalité principale (ajouter, modifier, supprimer un article)
• Tests de validation de formulaire
• Au moins un test API avec la fixture request de Playwright
• Structure Page Object Model

Taille minimale viable : 15 à 20 tests qui passent vraiment. Qualité plutôt que quantité.

Une structure de répertoire qui reflète une vraie connaissance

my-playwright-tests/
├── playwright.config.ts
├── package.json
├── tests/
│   ├── auth/
│   │   ├── login.spec.ts
│   │   └── logout.spec.ts
│   └── items/
│       ├── create-item.spec.ts
│       ├── edit-item.spec.ts
│       └── delete-item.spec.ts
├── pages/
│   ├── BasePage.ts
│   ├── LoginPage.ts
│   └── ItemsPage.ts
└── utils/
    └── testHelpers.ts

Cette structure montre que vous comprenez le Page Object Model, l'organisation des tests et la séparation entre la logique de test et la logique de page. Un répertoire plat avec 20 fichiers .spec.ts à la racine montre le contraire.

Un README qui explique ce que vous avez construit

Rédigez un README qui couvre :

1. Ce que fait la suite de tests (quelle application, quels scénarios)

2. Comment l'exécuter (npm install && npx playwright test)

3. Quelles technologies sont utilisées (Playwright, TypeScript, pattern POM)

4. Ce que vous ajouteriez ensuite (montre que vous pouvez réfléchir au périmètre et aux priorités)

Gardez-le court, 200 à 400 mots. Le README est lu par les ingénieurs recruteurs qui décident de regarder le code ou non.

Ce qui fait ressortir le code de portfolio

La différence entre le code de portfolio qui impressionne et celui qu'on oublie :

// Faible
await expect(page).toHaveURL('/dashboard');

// Fort
await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
await expect(page.getByRole('navigation')).toContainText('admin@becomeqa.com');

Configurer le dépôt portfolio

# Initialiser un nouveau projet
mkdir my-playwright-portfolio
cd my-playwright-portfolio
npm init playwright@latest

# Choisir TypeScript quand demandé
# Sélectionner tests/ comme répertoire de tests
# Oui pour le workflow GitHub Actions

Ça vous donne une configuration Playwright fonctionnelle avec TypeScript et un fichier de workflow GitHub Actions qui exécute vos tests en CI.

Ajouter les tests

// tests/auth/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../../pages/LoginPage';

test.describe('Login', () => {
  test('user can log in with valid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login('admin@becomeqa.com', 'testpass123');
    
    await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
  });

  test('shows error with incorrect password', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login('admin@becomeqa.com', 'wrongpassword');
    
    await expect(page.getByText('Invalid credentials')).toBeVisible();
    await expect(page).not.toHaveURL('/dashboard');
  });
});

Pousser sur GitHub avec la CI qui passe

Le workflow GitHub Actions que npm init playwright@latest crée exécutera automatiquement vos tests à chaque push. Un pipeline CI qui passe est plus impressionnant que des tests qui "fonctionnent sur ma machine."

Vérifiez votre onglet Actions après le push. Si les tests passent : votre portfolio montre maintenant un pipeline CI en direct qui exécute des tests Playwright. C'est mieux que tout ce que vous pouvez écrire sur un CV.

S'ils échouent : corrigez-les avant de partager le lien.

Quoi inclure d'autre

Exemples de rapports de bug

Une collection de 3 à 5 rapports de bugs bien rédigés. Ils n'ont pas besoin de venir d'une entreprise. Ce peuvent être des bugs que vous trouvez sur n'importe quelle application publique, y compris lab.becomeqa.com.

Formatez-les exactement selon le modèle de rapport de bug : titre, environnement, préconditions, étapes, résultat attendu, résultat réel, sévérité, pièces jointes.

Mettez-les dans un dossier /bug-reports sous forme de fichiers markdown. Ça démontre les compétences de communication écrite et de rapport de bugs que les tests automatisés ne montrent pas.

Plan de test ou document de cas de test

Un court document montrant comment vous aborderiez le test d'une fonctionnalité depuis zéro. Choisissez une fonctionnalité spécifique (l'upload de fichiers sur lab.becomeqa.com, par exemple) et rédigez :

Décrivez les scénarios de test que vous couvririez, pourquoi vous les avez choisis, et ce que vous prioriseriez et pourquoi.

Ça démontre la réflexion sur la stratégie de test, pas seulement l'exécution.

Où partager votre portfolio

Erreurs courantes à éviter

// Mauvais
await page.fill('#email', 'admin@becomeqa.com');

// Mieux (bien que pour un portfolio, des identifiants de test codés en dur vers une app de test soient acceptables)
await page.fill('#email', process.env.TEST_EMAIL || 'admin@becomeqa.com');

FAQ

Construisez un portfolio en utilisant des environnements de test publics. lab.becomeqa.com existe pour ça. Autres options : the-internet.herokuapp.com, automationexercise.com, saucedemo.com. L'application n'a pas d'importance. La qualité du code, oui.

Un portfolio minimal viable (15 à 20 tests, structure POM, CI qui passe, README) prend 15 à 25 heures de travail concentré pour quelqu'un qui connaît Playwright. Si vous êtes encore en apprentissage, prévoyez 30 à 40 heures réparties sur quelques semaines.

Oui, si vous en avez. Un ou deux tests API avec la fixture request de Playwright montrent que vous comprenez la pile de test complète :

test('API : créer un article retourne 201', async ({ request }) => {
  const response = await request.post('/api/items', {
    data: { destination: 'Tokyo', status: 'Planned' },
    headers: { Authorization: `Bearer ${token}` },
  });
  expect(response.status()).toBe(201);
});

Oui, de façon notable. Les ingénieurs QA sans portfolio se battent sur le texte de leur CV. Les ingénieurs QA avec un portfolio donnent aux ingénieurs recruteurs quelque chose de concret à évaluer. En pratique, les propriétaires de portfolio progressent plus loin dans le processus de présélection dans les entreprises techniques.