La plupart des exercices QA à la maison ne sont pas difficiles. Ils sont ambigus, et l'ambiguïté est le test. Les candidats qui se font rejeter ont presque toujours livré quelque chose qui tournait.
Vous avez quatre heures ? Générez un exercice réaliste pour votre stack et votre séniorité, lancez un chrono, construisez-le contre un vrai site — puis revenez et notez-vous avec le barème ci-dessous, comme le ferait un relecteur.
Commencer un exercice d'entraînement — gratuit, sans inscription« Valider que les 100 premiers articles sont triés du plus récent au plus
ancien » prend vingt minutes à faire passer et quatre heures à rendre
défendable. Cet écart est tout le test. Un exercice à la maison existe pour
montrer si vous savez concevoir des vérifications et dire
pourquoi — n'importe qui peut apprendre page.locator() en une
semaine. Le relecteur lit votre code comme la preuve d'un raisonnement, et un
rendu incomplet avec un raisonnement clair bat systématiquement un rendu
complet sans aucun.
Ce qui est vraiment évalué : savez-vous gérer une cible que vous ne contrôlez pas — sélecteurs instables, données changeantes, pagination.
Survivez au changement de données en cours d'exécution, choisissez les sélecteurs par stabilité, et définissez « correct » dans le README — l'énoncé ne le fera pas. Répétez sur un vrai sandbox avant que le brief n'arrive.
Ce qui est vraiment évalué : la qualité des rapports de bug et le jugement de couverture — les sept vrais bugs, ou trente cosmétiques ?
Des constats ordonnés par impact, des étapes de repro exactes, une liste « ce que je n'ai pas couvert ». Le générateur de rapports de bug impose la forme.
Ce qui est vraiment évalué : pensez-vous en risque ou en checklists.
Un périmètre classé par risque, une liste explicite « ne teste pas », des critères d'entrée/sortie. Deux pages battent dix — le générateur de plan de test note le squelette.
Ce qui est vraiment évalué : contrats et cas limites, ou juste chemins nominaux.
Possédez votre préparation de données, faites vos assertions sur les corps pas les codes de statut, documentez au moins un bug planté. Le générateur de valeurs limites énumère les bords.
Ce qui est vraiment évalué : la correspondance — quels cas vous avez automatisés, et si vous savez défendre ceux que vous avez laissés manuels.
Énoncez la traçabilité clairement : « TC-03, 07, 11 automatisés ; TC-05 visuel, reste manuel ; TC-09 nécessite une vraie carte ».
Ce qui est vraiment évalué : savez-vous lire le code de quelqu'un d'autre et refactoriser sans le casser — généralement un signal de rôle senior.
De petits commits relisibles, et un README nommant chaque smell et ce que vous en avez fait.
Les six sont documentés publiquement. Les liens mènent à la source, pas à des solutions de candidats.
QA Wolf — tri Hacker News. Starter Playwright,
index.js vide : valider que les 100 premiers articles les plus
récents sont triés, plus une vidéo de deux minutes. La tâche la plus assignée
là-bas — traitée de
bout en bout ici.
cLabs (Celo) — Detox sur un clone d'Instagram. celo-org/qa-interview-assignment. Trois heures, plafonné. Distinctif : ils veulent un mélange de tests qui passent et qui échouent — qui échouent là où vous avez trouvé un vrai bug.
ZoomCare — page de planning. zoom-care/candidate-project-qa-automation. 8–10 cas de smoke, automatisez-en au moins trois ; forkez et ouvrez une PR — le README est le livrable.
DEPT — en deux parties. Publié sur leur site. Un plan de test sur six mois, puis une suite qui tourne. Distinctif pour tester la planification sur plusieurs mois.
Gumtree UK — E2E plus API. gumtreeuk/technical-assignment-qa. Des critères exceptionnellement explicites — page objects, rapports HTML, « commits git granulaires ». Vaut la lecture rien que comme grille publiée.
Moneyhub — Postman plus un formulaire cassé. moneyhub/qa-interview-task. ~30 minutes de travail d'API plus des cas manuels. Délibérément court — ils ne veulent pas de votre week-end.
La tâche QA Wolf Hacker News mérite sa propre page : le piège de la pagination, le bug de liste mouvante qui garde une mauvaise réponse au vert, la structure de fichiers, le README et la vidéo — le walkthrough complet. Le raisonnement se transfère à tout exercice « validez cette liste ».
Ces neuf lignes sont la revue. Cochez ce qui est vrai de votre rendu et regardez le score — la pondération reflète le déroulement réel des revues : si ça ne s'exécute pas, rien d'autre ne compte, et le README pèse plus que quiconque ne s'y attend.
0Cochez ce que votre rendu contient déjà.
Automatiser 30 éléments quand la tâche disait 100 — c'est ce qu'une seule page contient.
Comparer des chaînes de temps relatives au lieu d'horodatages absolus.
Des appels sleep fixes au lieu d'attendre une condition.
Aucune assertion — le script affiche des résultats et sort toujours en 0.
Committer node_modules, ou un .env avec une vraie clé.
Un README qui dit « lancez npm start » et rien d'autre.
Sur-construire — Docker et un reporter custom pour une tâche de quatre heures se lit comme un mauvais jugement.
Cacher silencieusement un bug que votre test aurait dû signaler.
Trente rapports de bugs cosmétiques et aucun des fonctionnels.
Ignorer une instruction explicite — le fichier, le framework, la vidéo qu'ils ont demandés.
Traitez « environ 4 heures » comme un budget : 30 minutes de lecture, 30 de cadrage sur papier, deux heures de construction, 30 sur les chemins d'échec, 30 sur le README. Si vous dépassez, arrêtez et notez ce qui manque — cette phrase note mieux que le travail supplémentaire, et vingt heures sur une tâche de quatre heures signalent que vous ne savez pas estimer. Quand c'est le code lui-même qui est fragile, c'est à ça que servent le Code Lab et le parcours.
La plupart des fourchettes annoncées sont de deux à quatre heures, et les exemples publiés le confirment — cLabs plafonne le sien à trois heures, ZoomCare à deux ou trois. Traitez le chiffre comme un budget. Dépasser largement signale une mauvaise estimation, que les relecteurs pèsent plus lourd qu'un rendu un peu plus mince.
Utilisez celui que vous savez expliquer sous questions, sauf si l'exercice en nomme un. Les relecteurs se soucient bien plus de votre conception de test et de votre structure que de votre outil. S'ils vous laissent choisir, ajoutez une ligne de README expliquant pourquoi vous l'avez choisi — cette phrase est notée.
Six sections : ce que fait le projet, les commandes exactes d'installation et de lancement depuis un clone propre, comment vous avez défini les critères d'acceptation que l'énoncé a laissés vagues, les limitations connues, ce que vous feriez avec plus de temps, et combien de temps vous avez passé. C'est le seul endroit où votre raisonnement est visible.
Oui, si vous le dites clairement. Un honnête « je n'ai pas automatisé le tunnel de paiement ; voici mon approche et l'estimation » se lit mieux qu'une version bâclée et instable de celui-ci. Les manques silencieux ressemblent à un oubli. Les manques nommés ressemblent à du contrôle de périmètre.
Moins que vous ne pensez, choisis délibérément. Trois tests bien structurés avec une justification énoncée battent quinze superficiels. Là où l'exercice donne un nombre, atteignez-le exactement, puis listez quels cas restants vous automatiseriez ensuite et lesquels devraient rester manuels.
Oui. Les critères publiés de Gumtree UK demandent explicitement des commits git granulaires montrant le cheminement de pensée. Un seul commit appelé « solution » ne donne rien aux relecteurs et invite au soupçon sur la provenance du code. Cinq commits qui suivent votre ordre de construction racontent une histoire qu'ils peuvent suivre.
Généralement un entretien de suivi où vous parcourez votre rendu et défendez vos choix. cLabs indique clairement qu'on vous demandera d'expliquer votre raisonnement. Notez pourquoi vous avez pris chaque décision importante tant que c'est frais, car on vous le demandera deux semaines plus tard.