SDET vs ingénieur QA : ce que ces intitulés signifient vraiment

La distinction qui survit d'une entreprise à l'autre porte sur la responsabilité. Un ingénieur QA possède le jugement qualité : quoi tester, quel risque on accepte, si cette release est sûre. Un SDET possède le code de test et les systèmes qui l'exécutent : le framework, les fixtures, le pipeline, les données de test, le reporting. Les deux rôles testent. Un seul est censé être relu par les développeurs comme un pair sur une pull request.

C'est la ligne qui vaut la peine d'être comprise, car elle vous dit ce qui change réellement quand vous évoluez. On ne vous demande pas d'arrêter d'être testeur pour devenir développeur. On vous demande d'ajouter une deuxième chose que vous possédez, et d'être jugé sur la qualité du code que vous écrivez pour le faire.

La version courte

Un ingénieur QA est responsable de savoir si le produit est bon. Un SDET est responsable de savoir si le produit est bon et de l'ingénierie qui le prouve, à une échelle qu'aucun humain ne pourrait parcourir au clic. Un ingénieur automatisation se situe généralement entre les deux : il écrit des tests dans un framework que quelqu'un d'autre a conçu, plutôt que de le concevoir.

La comparaison

La ligne qui compte le plus est rattaché à. Quand le SDET est rattaché à l'ingénierie, tout le reste suit : le standard de revue de code, l'implication dans la conception, et la façon dont le rôle est positionné par rapport aux développeurs.

Ce que chacun fait vraiment un mardi

Ingénieur QA. Lit un ticket qui dit « l'utilisateur peut mettre à jour son moyen de paiement ». Remarque qu'il ne dit pas ce qui se passe si la nouvelle carte échoue à l'autorisation en plein renouvellement d'abonnement. Pose la question en refinement. Cette question, c'est le travail. Puis conçoit les cas, exécute ceux qui nécessitent un humain, et ouvre deux bugs avec des étapes de reproduction assez claires pour que personne ne réponde « ça marche sur ma machine ».

Ingénieur automatisation. Prend cette même fonctionnalité et écrit la couverture de régression. Ajoute un page object, ajoute six specs, passe une heure sur celle qui est instable parce que la notification toast disparaît avant que l'assertion s'exécute. La corrige avec une vraie condition d'attente plutôt qu'un sleep, et passe à autre chose.

SDET. Se fait demander pourquoi la suite prend 40 minutes et échoue deux fois par semaine pour des raisons auxquelles personne ne fait confiance. Découvre que les tests partagent un seul compte amorcé, donc les exécutions parallèles entrent en collision. Reconstruit les données de test pour que chaque worker ait son propre tenant, répartit l'exécution sur quatre machines, ajoute un tag de quarantaine pour les specs connues comme instables afin qu'elles cessent de bloquer les merges, et écrit le rapport qui montre le taux d'instabilité baisser semaine après semaine.

Ce sont trois problèmes différents. Le troisième est un problème d'ingénierie qui se trouve porter sur les tests.

SDET vs ingénieur automatisation

Ces deux-là sont confondus plus souvent que SDET et QA, et la différence est facile à énoncer : un ingénieur automatisation est un consommateur d'un framework, un SDET en est un producteur.

Si vous savez écrire une spec Playwright mais ne sauriez pas expliquer pourquoi votre projet utilise des fixtures plutôt que des hooks beforeEach, comment le reporter est câblé, ou ce qui se passe quand un test échoue en CI mais passe en local, vous travaillez au niveau ingénieur automatisation. C'est un niveau réel et valorisé. C'est aussi le niveau où le plus grand nombre de personnes sont bloquées, parce qu'écrire plus de specs ne vous enseigne jamais automatiquement l'architecture. Il faut aller la chercher séparément.

Le test pratique : pourriez-vous démarrer un nouveau dépôt demain et monter un framework de test dans lequel une équipe de six personnes pourrait travailler deux ans sans vous détester ? Config par environnement, auth gérée une seule fois, données parallèle-safe, artefacts d'échec sensés, intégration CI, une structure de dossiers défendable. Si oui, vous passez les entretiens comme un SDET quel que soit votre intitulé actuel — la banque de questions SDET est le moyen le plus rapide de vous tester face à ce que ces process sondent réellement.

Le recoupement que personne ne mentionne

Les bons SDET sont généralement d'excellents testeurs manuels. Pas occasionnellement — généralement.

La raison est que l'automatisation ne fait qu'encoder des décisions que quelqu'un a déjà prises. Si vous ne pouvez pas dire lesquelles des quarante vérifications possibles sur un tunnel de paiement comptent vraiment, vous les automatiserez toutes les quarante, et vous voilà avec une suite lente qui échoue sans cesse et ne teste rien d'important. La conception de test est en amont du code de test. Quelqu'un qui a passé trois ans à trouver de vrais bugs à la main a cet instinct. Quelqu'un passé directement d'un bootcamp à Selenium ne l'a généralement pas, et ne sait pas que ça lui manque.

C'est la partie de votre bagage manuel qui est un atout, et elle vaut la peine d'être dite à voix haute en entretien. Pas « j'ai fait du test manuel pendant quatre ans », qui sonne comme une excuse. Plutôt : « j'ai vu comment ce tunnel casse en production, alors voici ce que je couvrirais en premier et ce que je laisserais délibérément hors de la suite automatisée ».

Lequel viser ?

Visez SDET si vous aimez les systèmes, voulez relever votre plafond, et êtes prêt à passer du vrai temps à être mauvais en programmation avant d'être bon. Le rôle a la plus longue piste de décollage, et il se convertit en ingénierie de plateforme, en developer experience et en management d'ingénierie plus facilement qu'une voie QA. Ce sur quoi chaque échelon est jugé, et le point où la plupart des gens stagnent, est exposé dans l'échelle de carrière QA.

Restez sur la voie de l'ingénierie QA si ce que vous aimez, c'est le produit, les utilisateurs et la décision de risque. Cette voie va d'ingénieur QA à lead QA à responsable qualité, et aux niveaux seniors c'est un métier de stratégie. C'est un marché de l'emploi plus petit avec moins de points d'entrée, et il récompense les gens qui y excellent plutôt que ceux qui sont simplement compétents.

La seule chose qui ne marche pas dans le marché actuel, c'est de rester à « j'exécute des cas de test écrits par quelqu'un d'autre » et d'attendre que le rôle conserve sa valeur. Cette position est comprimée des deux côtés — par l'automatisation en dessous et par la génération de tests assistée par IA à côté. La version longue de cet argument est dans le test manuel est-il en train de mourir ?

Comment les recruteurs lisent vraiment votre CV

Un parseur le lit généralement avant qu'un humain ne le fasse ; le vérificateur de CV ATS montre ce qu'il extrait réellement du vôtre. Ce que l'humain cherche ensuite, ce sont trois signaux, à peu près dans cet ordre :

1. Savez-vous écrire du code qui survit à une revue ? Un dépôt public avec un petit framework propre bat « 5 ans d'expérience en automatisation » sur une liste à puces. On survolera vos commits. Le Code Lab est l'endroit où vous construisez ce muscle sans configuration locale.
2. Comprenez-vous l'échec ? N'importe qui sait décrire un test qui passe. Expliquer un test instable précis que vous avez diagnostiqué, sa cause, et ce que vous avez changé sépare la vraie expérience de la simple complétion d'un cours.
3. Prenez-vous les décisions ou les recevez-vous ? « On a automatisé la suite de régression » est une phrase sur une équipe. « J'ai défendu l'idée de ne pas automatiser les vérifications d'export PDF parce que les différences de rendu étaient cosmétiques, et voici ce qu'on a fait à la place » est une phrase sur vous.

Aucun de ces signaux ne demande la permission de votre employeur actuel. Vous pouvez les construire tous les trois sur votre temps libre, ce qui est la seule option réaliste quand votre intitulé dit QA manuel et que votre entreprise n'a aucune automatisation sur laquelle travailler.