Le métier d’automaticien de tests : missions et compétences

Avant d’apprendre Java, avant d’ouvrir Selenium, il faut savoir ce qu’on vous demandera de faire. Ce chapitre décrit le métier en termes de tâches réelles, puis vous fait situer votre point de départ. Comptez une quinzaine de minutes : dix de lecture, cinq pour l’auto-positionnement de la fin, que vous devez écrire quelque part et garder.

Ce que fait un automaticien de tests, concrètement

Un automaticien de tests écrit et maintient du code dont le seul but est de vérifier qu’une autre application fonctionne. Ce code ouvre un navigateur, remplit des formulaires, clique, lit ce qui s’affiche, compare avec ce qui était attendu, et produit un rapport.

Une semaine type contient, dans des proportions variables selon les équipes :

• lire une spécification ou une user story, et décider quels cas méritent d’être automatisés ;
• écrire le script correspondant, dans un langage de programmation ;
• le faire tourner, constater qu’il échoue, et déterminer si c’est l’application qui a un défaut ou le script qui est mal écrit ;
• réparer des scripts qui marchaient hier et qui ne marchent plus parce qu’un développeur a renommé un identifiant HTML ;
• expliquer à quelqu’un pourquoi un test est rouge.

Ce dernier point mérite d’être souligné : une part du travail consiste à distinguer un vrai défaut d’un test instable. C’est une compétence d’enquête, pas de saisie.

Le support d’origine de cette formation résume le métier en quatre familles de compétences. Nous les gardons, et nous précisons pour chacune ce que vous faites réellement.

Où le métier se situe : QM, QA, QC

Trois niveaux sont souvent confondus. Les distinguer aide à situer votre rôle, en entretien comme en projet.

L’automatisation se place à cheval sur QA et QC : vous concevez des cas de test (QA) et vous fabriquez le moyen de les exécuter en série (QC). Vous n’êtes pas seulement l’exécutant d’un plan écrit par un autre, et vous n’êtes pas non plus celui qui définit la politique de test de l’entreprise. Cette position intermédiaire explique pourquoi le métier demande à la fois de coder et de comprendre le test.

Les quatre familles de compétences

Famille 1 — Programmation

Ce que vous faites. Vous écrivez du code dans un langage généraliste : Java, Python ou C# selon les équipes. Ce parcours utilise Java. Concrètement, sur une journée, vous manipulez des variables, des conditions, des boucles, des listes, des méthodes, des classes ; vous lisez un message d’erreur du compilateur et vous le corrigez ; vous découpez un script de deux cents lignes en morceaux réutilisables pour ne pas récrire trois fois la même séquence de connexion.

Ce que ça n’est pas. Vous ne développez pas l’application testée. Vous n’avez pas besoin de connaître les frameworks web côté production. Mais vous écrivez du vrai code, compilé, versionné, relu — pas des macros enregistrées.

Le signe que vous n’y êtes pas encore. Vous savez lire du code et suivre ce qu’il fait, mais devant une page blanche vous ne savez pas par quoi commencer. Si c’est votre cas, c’est exactement ce que les chapitres d’algorithmique et de Java traitent.

Famille 2 — Outils d’automatisation

Ce que vous faites. Vous pilotez un navigateur depuis votre code avec Selenium, vous organisez vos tests avec JUnit 5 ou TestNG, et vous gérez les dépendances et l’exécution avec Maven. Au quotidien, cela veut dire : inspecter une page web pour trouver comment désigner un bouton de façon stable, choisir entre un identifiant, une classe CSS ou un XPath, et faire attendre le script jusqu’à ce que l’élément soit réellement là.

Voici à quoi ressemble le code produit par cette famille. Il est en Selenium 4 et il compile tel quel, une fois les dépendances Maven en place et Chrome installé sur la machine :

import java.time.Duration;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class ConnexionSwagLabs {

    public static void main(String[] args) {
        WebDriver driver = new ChromeDriver();
        try {
            driver.get("https://www.saucedemo.com/");

            driver.findElement(By.id("user-name")).sendKeys("standard_user");
            driver.findElement(By.id("password")).sendKeys("secret_sauce");
            driver.findElement(By.id("login-button")).click();

            WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
            wait.until(ExpectedConditions.urlContains("/inventory.html"));

            System.out.println("Connexion OK : " + driver.getCurrentUrl());
        } finally {
            driver.quit();
        }
    }
}

Ne cherchez pas à l’exécuter maintenant : il suppose un projet Maven configuré, ce qui fait l’objet d’un chapitre entier plus loin. Il est ici pour une seule raison : vous montrer la taille et la forme de ce que vous écrirez. Notez au passage qu’il n’y a aucun téléchargement de driver ni aucune ligne de configuration de chemin : depuis la version 4.6, Selenium récupère lui-même le driver correspondant au navigateur installé.

Une dizaine de lignes utiles, dont une, wait.until(...), existe uniquement parce que le web est lent et asynchrone. C’est cette ligne-là, et pas les trois findElement, qui sépare un script qui passe une fois d’un script qui passe tous les jours.

Le signe que vous n’y êtes pas encore. Vous comprenez le code ci-dessus en le lisant, mais vous ne sauriez pas quoi faire si le champ user-name n’avait pas d’attribut id. Comprendre du code et savoir en produire sont deux états différents ; le chapitre Selenium travaille le second.

Famille 3 — DevOps et CI/CD

Ce que vous faites. Vos tests ne servent à rien s’ils ne tournent que sur votre machine, le jour où vous y pensez. Cette famille couvre ce qui les déclenche automatiquement : un serveur d’intégration continue (Jenkins, GitLab CI/CD ou équivalent) qui, à chaque modification du code envoyée par un développeur, récupère le dépôt, compile, exécute la campagne et publie le résultat.

Au quotidien : écrire un fichier de configuration de pipeline, comprendre pourquoi un test qui passe chez vous échoue sur le serveur (pas de navigateur graphique, données différentes, fuseau horaire différent), et savoir lire des journaux d’exécution sans avoir l’écran sous les yeux.

Le signe que vous n’y êtes pas encore. Vous ne savez pas nommer ce qui se passe entre « le développeur pousse son code » et « quelqu’un reçoit un rapport de test ». Ce n’est pas bloquant pour écrire vos premiers tests.

Famille 4 — Concepts de test

Ce que vous faites. Vous décidez quoi tester, à quel niveau, et quoi automatiser en premier. Cela suppose de connaître les niveaux de test — unitaire, intégration, système, acceptation — et les types — non-régression, bout en bout, performance, sécurité, utilisabilité — et de savoir qu’un même type se pratique à plusieurs niveaux.

Cela suppose aussi un critère de sélection des candidats à l’automatisation. Le support d’origine en retient quatre, et ils tiennent : un test mérite d’être automatisé s’il est récurrent, s’il porte sur un risque élevé, s’il est coûteux en temps à exécuter à la main, et s’il est techniquement automatisable. Un test qu’on exécutera une seule fois, sur une fonctionnalité secondaire, en deux minutes, ne mérite pas trois heures de script.

Le signe que vous n’y êtes pas encore. Vous automatiseriez « tout », dans l’ordre où les fonctionnalités apparaissent à l’écran. Savoir dire non à un test est une compétence à part entière.

L’horizon : le « Full Stack QA »

Le support d’origine décrit un profil plus large, dit Full Stack QA : quelqu’un qui automatise l’interface et les services backend, mène des tests de performance, des tests de sécurité, des tests mobiles sur Android et iOS, exécute des campagnes dans le cloud, et prend assez de recul pour remettre en question les processus et les outils d’une équipe.

C’est une trajectoire, pas un point de départ. Ce chapitre ne vous promet pas d’y arriver, et aucun parcours ne peut le promettre. Retenez-en seulement la direction : chacune de ces spécialités part des quatre familles ci-dessus.

Ce que le Niveau 1 couvre, et ce qu’il ne couvre pas

Dit sans détour, ce Niveau 1 ne couvre pas :

• les tests mobiles (Android, iOS, Appium) ;
• les tests d’API et de services backend ;
• les tests de performance et de charge ;
• les tests de sécurité ;
• l’exécution dans le cloud et sur parcs de navigateurs distants.

Ces cinq domaines sont mentionnés pour que vous sachiez qu’ils existent et où ils se rangent. Ils ne sont pas enseignés ici.

Auto-positionnement : quatre questions

Répondez aux quatre questions, une par famille, avec la même échelle. Écrivez vos réponses dans un fichier que vous garderez — vous le relirez à la fin du parcours.

Question 1 — Programmation. Sauriez-vous écrire, sans aide et sans copier un exemple, un programme Java qui parcourt une liste de dix prénoms et affiche uniquement ceux qui commencent par la lettre A ?

Question 2 — Outils d’automatisation. En relisant le script ConnexionSwagLabs plus haut : sauriez-vous expliquer ligne par ligne ce qu’il fait, et dire ce qui se passerait si la page mettait quatre secondes à afficher le champ user-name ?

Question 3 — DevOps et CI/CD. Sauriez-vous décrire ce qui se produit, étape par étape, entre le moment où un développeur envoie une modification de code et le moment où un rapport de test automatisé est disponible ? Sauriez-vous nommer un outil qui fait cela ?

Question 4 — Concepts de test. Sauriez-vous expliquer la différence entre un test unitaire et un test de bout en bout, puis dire lequel des deux vous automatiseriez en premier sur un nouveau projet, en justifiant votre choix ?

Une vérification rapide avant la question 1

Ouvrez un terminal et tapez :

java -version

Pour ouvrir un terminal :

Vous devez voir trois lignes. La première ressemble à ceci, le numéro exact après 11.0. variant d’une installation à l’autre :

openjdk version "11.0.22" 2024-01-16

Certaines installations affichent java version "11.0.22" au lieu de openjdk version. Les deux conviennent.

Si vous voyez une erreur. Sous Linux ou macOS, le message ressemble à bash: java: command not found, ou commande introuvable sur un système en français. Sous Windows, PowerShell répond par une ligne qui commence par java : et contient « n’est pas reconnu comme nom d’applet de commande ». Dans tous ces cas, Java n’est pas installé ou n’est pas dans le PATH. À ce stade, ce n’est pas un problème et cela ne change pas votre note à la question 1 : le chapitre d’installation de l’environnement traite ce point en détail. Notez seulement le message exact que vous avez obtenu, il servira là-bas.

Si la commande ne rend pas la main ou si rien ne s’affiche, fermez la fenêtre, rouvrez un terminal et retapez la commande en vérifiant qu’il n’y a qu’un seul tiret devant version.

Si vous voyez une version 8, 17 ou 21, ne changez rien pour l’instant. Le parcours utilise Java 11, et le chapitre d’installation explique comment faire cohabiter plusieurs versions.

Que faire de votre score

• 0 partout. C’est le point de départ prévu par ce parcours. Suivez les chapitres dans l’ordre, sans en sauter : l’algorithmique avant Java, Java avant Selenium. La tentation d’aller directement à Selenium parce que c’est là que « ça bouge » est réelle ; le risque l’est aussi, et il est concret : on copie du code sans pouvoir le modifier, et on bloque à la première page qui ne ressemble pas à l’exemple.
• 2 ou 3 à la question 1, 0 ailleurs. Vous savez programmer. Les chapitres Java vous serviront de révision rapide ; ne les sautez pas entièrement, la POO est utilisée sans ménagement dans la partie Selenium.
• 1 partout. Attention au piège : « je comprends quand je lis » n’est pas « je sais écrire ». Un moyen de trancher, pour la question 1 : fermez cette page et écrivez le programme des dix prénoms. Si vous rouvrez un exemple au bout de deux minutes, votre note est 1, pas 2.
• Rien du tout à la question 3. C’est prévu, et sans conséquence pour la suite du Niveau 1.

Aucune de ces réponses ne vous disqualifie. Elles déterminent seulement le temps que vous passerez sur chaque chapitre.

Vérifier que ce chapitre est acquis

Sans revenir en arrière, vous devez pouvoir écrire quatre lignes de cette forme, de mémoire :

Programmation           : note __  - ce que j'y fais : ...
Outils d'automatisation : note __  - ce que j'y fais : ...
DevOps et CI/CD         : note __  - ce que j'y fais : ...
Concepts de test        : note __  - ce que j'y fais : ...

Si un nom de famille vous manque, relisez la section correspondante. Si c’est le « ce que j’y fais » qui vous manque, c’est plus important : c’est cette partie-là qui compte, bien davantage que la liste des quatre mots.

Vous devez également pouvoir citer sans hésiter les cinq domaines que ce Niveau 1 ne traite pas.

Ce qui suit

Le chapitre suivant installe l’environnement de travail : JDK 11, Maven 3, VS Code, et la vérification que chaque brique répond correctement avant d’écrire la première ligne de code. Gardez le message d’erreur de java -version si vous en avez obtenu un.