Portfolio de testeur QA junior : 5 projets à montrer

Quand on débute ou qu'on se reconvertit dans le test logiciel, un portfolio montre ce que le CV ne peut pas montrer : votre façon de penser un test, de décrire un défaut et d'automatiser. Il ne faut pas dix projets, mais cinq projets bien présentés. Voici lesquels, comment les présenter et les erreurs à éviter. Ces conseils sont ceux d'ADC, pas le résultat d'une étude auprès des recruteurs, et aucun portfolio ne garantit un poste.

Ce que le portfolio doit montrer

Un portfolio répond à une question simple : cette personne sait-elle tester ? Il doit donc montrer des raisonnements (comment vous choisissez des cas de test), de la rigueur (comment vous décrivez un défaut) et un début d'automatisation. Pour savoir quelles compétences reviennent dans les annonces, consultez notre baromètre des compétences QA en France.

Les cinq projets

1. Un plan de test et des cas sur une application publique

Choisissez une application publique de démonstration, définissez ce que vous testez et pourquoi, puis écrivez des cas de test avec leurs données et leurs résultats attendus. Montrez que vous savez choisir : partitions d'équivalence, valeurs limites. Un classeur bien tenu vaut mieux qu'un long document. Le modèle de cahier de recette Excel gratuit fournit la structure (cas de test, registre des anomalies, synthèse, matrice de traçabilité).

2. Un rapport de bug exemplaire

Un bon rapport tient en quelques lignes : titre précis, étapes de reproduction numérotées, résultat obtenu, résultat attendu, environnement, capture ou vidéo. Publiez-en deux ou trois sur des défauts réels trouvés dans l'application choisie.

3. Un test API automatisé

Écrivez quelques tests sur une API publique : statut, contenu de la réponse, cas d'erreur. Notre article sur les tests API compare les outils les plus utilisés ; le choix de l'outil compte moins que la clarté des vérifications.

4. Un test E2E Playwright dans un dépôt GitHub propre

Automatisez un parcours complet de l'application avec Playwright : un dépôt avec un README (comment installer et lancer les tests), des locators lisibles et quelques assertions. Le cours Playwright gratuit en PDF vous guide pour ce projet, et notre article sur les locators Playwright aide à écrire des tests lisibles.

5. Un rapport de recette ou d'audit (modèle)

Rédigez un court rapport de synthèse : ce qui a été testé, les anomalies trouvées, les risques restants, une recommandation. Notre exemple de rapport d'audit QA, bâti sur un client fictif, montre une structure possible ; adaptez-la à votre projet sans la recopier.

Comment présenter chaque projet

• Un README par projet : le contexte, ce que vous avez testé, comment relancer, ce que vous avez appris.
• Des captures et des résultats : un rapport d'exécution lisible vaut mieux qu'une description.
• Un fil conducteur : la même application pour les cinq projets montre une démarche complète.

Erreurs fréquentes

• Recopier un tutoriel tel quel, sans l'adapter ni expliquer vos choix.
• Publier un dépôt sans README, ou des tests qui ne se lancent pas.
• Empiler des projets sans fil conducteur.
• Mettre des données ou des identifiants réels dans un dépôt public.
• Gonfler son niveau : mieux vaut un projet simple et honnête qu'un projet copié.