Entraînement aux exercices QA à la maison
Génère un exercice d'automatisation réaliste contre un vrai site d'entraînement public, avec la liste de tâches, les livrables, la grille pondérée sur laquelle les relecteurs notent, et les quatre raisons pour lesquelles les rendus sont rejetés.
Choisissez une stack, un niveau de séniorité et un budget-temps. Puis lancez un minuteur et faites-le vraiment — avant qu'un vrai arrive avec une échéance attachée.
Ouvrir l'outil — gratuit, sans inscriptionCe qu'il y a dans l'exercice
Trois menus déroulants produisent un énoncé complet en Markdown. Cinq stacks, chacune pointée vers une vraie cible publique : Playwright + Python et Selenium + Java contre SauceDemo, Cypress + JavaScript contre l'appli de démo TodoMVC, et le test d'API en pytest ou Rest Assured contre ReqRes. Quatre niveaux de séniorité contrôlent combien de tâches vous obtenez — junior reçoit les quatre de base, mid et senior en ajoutent trois, lead en ajoute deux de plus. Les budgets-temps vont de 3 à 8 heures.
Pour les stacks UI, les quatre tâches de base sont : automatiser la connexion y compris un cas d'échec, automatiser un parcours d'achat end-to-end jusqu'à l'état de confirmation, implémenter le Page Object Model sans sélecteurs bruts dans les fichiers de test, et rendre la suite pilotée par les données sur plusieurs jeux d'entrée.
Pour les stacks API : automatiser le cycle de vie CRUD complet en affirmant les codes de statut et les corps, ajouter la validation de schéma pour qu'un type de champ modifié fasse échouer le test plutôt qu'une seule valeur modifiée, couvrir les cas négatifs, et gérer l'auth — y compris prouver qu'une requête non authentifiée est rejetée.
Mid et au-dessus ajoutent le câblage CI avec le rapport en artefact, des données de test qui survivent à l'exécution parallèle, et la documentation d'un échec instable que vous avez rencontré ou prévoyez. Lead ajoute une stratégie d'une page — ce que vous automatiseriez, ce que vous n'automatiseriez délibérément pas, et pourquoi — plus comment le framework passe à l'échelle de 20 ingénieurs et 500 tests, en nommant la première chose qui casserait.
La grille
À lire avant d'écrire la moindre ligne de code, car c'est là que les candidats mal répartissent l'effort :
| Poids | Critère |
|---|---|
| 30 % | Justesse — les assertions vérifient réellement le comportement ; aucun test incapable d'échouer |
| 25 % | Conception et structure — séparation des préoccupations, pas de duplication, un nouvel arrivant s'y repère en dix minutes |
| 20 % | Fiabilité — pas de sleeps en dur, des attentes correctes, passe de façon répétée plutôt qu'une seule fois |
| 15 % | Jugement de couverture — des scénarios à haute valeur choisis, et vous pouvez justifier ce que vous avez laissé de côté |
| 10 % | Communication — un README couvrant comment le lancer, les compromis, et ce que vous feriez avec plus de temps |
Le volume n'est noté nulle part. Dix tests significatifs avec une structure propre battent quarante superficiels, et la grille est la raison.
Comment l'utiliser
Choisissez la stack sur laquelle vous seriez vraiment interviewé, réglez la séniorité un niveau au-dessus de votre poste actuel, et choisissez un budget-temps que vous respecterez vraiment. Générez, copiez le Markdown, puis lancez un minuteur et arrêtez quand il expire. La contrainte est l'exercice — les relecteurs évaluent le jugement sous pression de temps, pas l'endurance. Finissez par le README : c'est 10 pour cent du score et la section la plus souvent sautée.
Ce qui fait échouer les rendus
Des attentes codées en dur. sleep(5)
disséminé dans la suite est la raison de rejet la plus courante. Utilisez le
mécanisme d'attente du framework.
Quarante tests superficiels au lieu de dix significatifs. Les relecteurs lisent un échantillon, pas tout. Le remplissage est visible immédiatement.
Pas de README. Si le relecteur ne peut pas le lancer, le code n'est pas évalué du tout.
Des sélecteurs dupliqués entre fichiers de test. C'est ce que l'exigence du Page Object teste, et la duplication montre que le pattern a été appliqué de façon cosmétique.
Ignorer le budget-temps. Vingt heures sur une tâche de quatre heures n'est pas la victoire qu'on croit — le README est là où vous dites ce que vous auriez fait avec plus de temps, et cette réponse score mieux que le travail supplémentaire ne l'aurait fait.
La génération se fait dans votre navigateur ; rien n'est envoyé où que ce soit. Le dépôt terminé vaut aussi plus qu'un certificat — un dépôt public avec un framework propre et un README honnête répond aux questions avant qu'elles soient posées.
Si vous voulez voir la vraie chose avant de vous entraîner contre une version générée, nous gardons une page compagnon de vrais exercices QA à la maison — six archétypes, des dépôts publics d'entreprises qui les envoient vraiment, la grille sur laquelle les relecteurs notent, et une tâche travaillée de bout en bout.
Questions fréquentes
En quoi consiste un exercice QA à la maison ?
Généralement à construire une petite suite d'automatisation contre une application de démo : un flux de connexion avec un cas d'échec, un parcours end-to-end, le Page Object Model, et des tests pilotés par les données. Les exercices d'API couvrent le CRUD, la validation de schéma, les cas négatifs et l'authentification. Un README expliquant vos décisions est attendu.
Combien de temps devrait prendre un exercice à la maison ?
La plupart spécifient 3 à 8 heures de travail, souvent dans une fenêtre de rendu de 48 heures. Respectez le budget annoncé — les relecteurs évaluent le jugement sous contraintes. Si vous manquez de temps, documentez ce que vous auriez fait ensuite ; ça score mieux qu'un rendu sur-livré.
Sur quoi les relecteurs notent-ils un exercice à la maison ?
La justesse des assertions pèse le plus, puis la conception et la structure, puis la fiabilité, le jugement de couverture, et la communication. Notamment, le nombre de tests n'est pas un critère. Dix tests bien conçus avec un README clair battent quarante superficiels.
Où puis-je m'entraîner à l'automatisation QA gratuitement ?
Ce générateur cible trois sites publics : SauceDemo pour les flux de boutique UI, l'appli de démo TodoMVC pour Cypress, et ReqRes pour l'entraînement à l'API REST. Les trois sont ouverts, stables, et destinés à l'entraînement à l'automatisation, donc vous pouvez compléter l'exercice de bout en bout. Pour un ensemble plus large — quatre sandbox UI et quatre API, chacune avec une mission d'entraînement précise — voyez notre guide sur où s'entraîner à l'automatisation QA.
Un exercice à la maison terminé vaut-il la peine d'être mis sur GitHub ?
Oui. Un dépôt public avec un framework qui fonctionne et un README honnête est une preuve plus forte que n'importe quel certificat, et il donne aux examinateurs quelque chose de concret à discuter. Écrivez le README comme si un relecteur qui ne vous a jamais rencontré allait le lancer.