De QA fonctionnel à automaticien : la carte des compétences réelles

« Je veux passer à l’automatisation. Par quoi je commence ? »

C’est la question la plus fréquente que nous recevons de testeurs fonctionnels confirmés. La réponse habituelle — « apprends Selenium » — est mauvaise, et elle explique une bonne partie des reconversions qui s’arrêtent au bout de trois mois.

Voici la carte des compétences réellement nécessaires, dans l’ordre où elles servent.

Ce que vous savez déjà, et qui compte plus que vous ne le pensez

Commençons par là, parce que c’est ce qu’on oublie de dire aux gens en reconversion.

Un testeur fonctionnel confirmé possède trois choses qu’un développeur qui se met au test met des années à acquérir :

• savoir ce qui vaut la peine d’être testé. C’est la compétence la plus rare de l’automatisation. Une équipe qui ne l’a pas produit trois mille tests qui vérifient tous la même chose sous des angles différents ;
• connaître le domaine métier. Vous savez qu’un avoir n’est pas un remboursement, qu’un contrat suspendu n’est pas un contrat résilié. Aucun outil ne compense cette connaissance ;
• savoir écrire un cas de test. Préconditions, action, résultat attendu. C’est exactement la structure d’un test automatisé — vous en connaissez déjà la grammaire.

L’automatisation n’est pas un nouveau métier. C’est votre métier, avec un moyen d’exécution différent.

Le vrai point de bascule : écrire du code, pas utiliser un outil

Voici l’erreur de cadrage la plus coûteuse : croire qu’automatiser consiste à apprendre un outil.

Un framework d’automatisation est un projet logiciel. Il a une architecture, des dépendances, une dette technique, des revues de code et un cycle de vie. Les personnes qui réussissent leur transition sont celles qui l’acceptent tôt. Celles qui décrochent sont presque toujours celles à qui on a vendu l’automatisation comme une activité de configuration.

Concrètement, cela veut dire que le premier sujet n’est pas Selenium. C’est le langage.

Étape 1 — Un langage, vraiment

Objectif : écrire et lire du code sans être ralenti par la syntaxe.

Choisissez-en un — Java, TypeScript, Python, peu importe — et tenez-vous-y un an. La dispersion est le premier facteur d’échec.

Ce qu’il faut maîtriser, et rien de plus au départ :

• types, variables, conditions, boucles ;
• collections : listes, dictionnaires, et surtout leur parcours ;
• fonctions, paramètres, valeurs de retour ;
• classes, attributs, méthodes, instanciation ;
• gestion des exceptions ;
• lecture d’une pile d’appels, ce qui est une compétence à part entière.

Ce dont vous n’avez pas besoin pour commencer : les patrons de conception avancés, la programmation fonctionnelle, la concurrence. Ils viendront par nécessité, pas par programme.

Signe que l’étape est franchie : vous pouvez lire un test écrit par quelqu’un d’autre et dire ce qu’il vérifie, sans l’exécuter.

Étape 2 — Le test unitaire, avant le test d’interface

C’est l’étape que presque tous les parcours sautent, et c’est une erreur.

Apprendre JUnit ou son équivalent avant Selenium vous apprend la structure d’un test automatisé dans son environnement le plus simple : pas de navigateur, pas d’attente, pas d’instabilité. Juste une entrée, une action, une assertion.

@Test
void shouldApplyDiscountOnlyAboveThreshold() {
    Cart cart = new Cart();
    cart.add(new Item("clavier", 45.00));

    // Sous le seuil : aucune remise.
    assertThat(cart.total()).isEqualTo(45.00);

    cart.add(new Item("écran", 180.00));

    // Au-dessus du seuil : remise de 10 %.
    assertThat(cart.total()).isEqualTo(202.50);
}

Vous y apprenez les annotations de cycle de vie, les assertions, les tests paramétrés, le mocking. Tout cela se transpose ensuite intégralement au test d’interface — mais vous l’aurez appris sans vous battre contre un navigateur en même temps.

Signe que l’étape est franchie : vous savez expliquer pourquoi une assertion vaut mieux qu’un System.out.println.

Étape 3 — Git, avant tout le reste de l’outillage

Votre code de test vit dans un dépôt partagé. Sans Git, vous ne pouvez ni collaborer, ni revenir en arrière, ni comprendre pourquoi un test a été modifié.

Le minimum utile : clone, branch, commit, push, pull request, et savoir résoudre un conflit sans paniquer. Rien de plus au départ.

Étape 4 — L’automatisation d’interface, enfin

Maintenant seulement, Selenium ou Playwright.

Et ce que vous y apprenez tient en trois sujets, qui causent à eux seuls la quasi-totalité des échecs :

Les sélecteurs. Comment désigner un élément de façon stable. Un XPath qui décrit un chemin dans l’arborescence casse au premier changement de mise en page. Un attribut dédié au test ne casse jamais. C’est une discussion à avoir avec vos développeurs, pas un problème à résoudre seul.

Les attentes. La cause numéro un de l’instabilité. Thread.sleep(3000) n’est pas une attente : c’est un pari. Il faut attendre une condition — que l’élément soit cliquable, que la requête soit terminée — jamais une durée.

Le Page Object Model. La règle est simple et rarement respectée : aucun sélecteur ne doit apparaître dans un test. Si vous voyez un By.id(...) dans une méthode annotée @Test, l’abstraction a déjà fui.

// Ce que le test doit dire : l'intention métier.
@Test
void shouldRejectExpiredCard() {
    checkoutPage.payWith(EXPIRED_CARD);
    assertThat(checkoutPage.errorMessage())
        .isEqualTo("Cette carte a expiré.");
}

Le test parle de cartes et de paiement. Pas de div, pas de input, pas de click(). Toute la connaissance du DOM est enfermée dans checkoutPage.

Étape 5 — Le test d’API, qui aurait presque dû venir avant

La plupart des scénarios que vous automatiserez en interface devraient être des tests d’API.

C’est contre-intuitif quand on vient du test fonctionnel, où tout passe par l’écran. Mais un test d’API est dix à cinquante fois plus rapide, il n’a aucune instabilité de rendu, et il localise mieux la panne : quand il échoue, vous savez que le problème est côté serveur.

La règle pratique : testez en interface ce qui EST l’interface. La navigation, l’affichage, l’accessibilité. Tout le reste — les règles métier, les cas d’erreur, les combinaisons — descend d’un niveau.

Une équipe qui fait ce déplacement divise typiquement par cinq le temps d’exécution de sa campagne et supprime l’essentiel de son instabilité.

Étape 6 — La chaîne d’intégration

Un test qui ne tourne que sur votre poste ne protège personne.

Ce qu’il faut comprendre : comment un pipeline exécute vos tests, comment lire un rapport d’échec sans rejouer le test en local, et comment paralléliser. Puis Docker, parce qu’il résout le problème du « ça marche chez moi » de façon définitive.

Signe que l’étape est franchie : un collègue peut comprendre pourquoi votre test a échoué en lisant le rapport, sans vous appeler.

Ce que ce parcours n’apprend pas, et qu’il faut chercher ailleurs

La revue de code. Vous devez faire relire votre code de test par quelqu’un qui code. C’est le mécanisme d’apprentissage le plus efficace, et le plus souvent absent des reconversions solitaires.

La mise en situation. Lire trois cents pages sur les patrons de conception ne remplace pas une semaine à automatiser quatre applications réelles avec leurs contraintes. C’est précisément pour cette raison que notre parcours de formation est construit autour d’une équipe QA simulée, où chacun est propriétaire de ses user stories, plutôt qu’autour d’exercices corrigés.

Le droit de supprimer. Un automaticien mûr supprime des tests. C’est une compétence, et elle s’acquiert difficilement seul, parce qu’elle demande d’assumer une décision.

Combien de temps

Six à douze mois pour être autonome sur une suite existante, en y consacrant du temps régulièrement. Deux à trois ans pour concevoir une architecture de framework qui tienne.

Quiconque vous promet deux semaines vous vend une certification, pas une compétence.

Le piège à éviter

Le piège classique de la reconversion, c’est de vouloir tout automatiser dès qu’on sait le faire. On écrit deux cents tests en trois mois, on est fier, et six mois plus tard la suite est rouge en permanence et plus personne ne la regarde.

Le bon réflexe est l’inverse : automatisez peu, automatisez ce qui casse, et supprimez ce qui ne trouve jamais rien. Une suite de quarante tests à laquelle l’équipe fait confiance protège infiniment mieux qu’une suite de quatre cents qu’on relance.