Questions d'entretien SDET

Un ingénieur QA porte le jugement qualité : quoi tester, quel risque on porte, si cette release est sûre. Un SDET porte cela plus l'ingénierie qui le prouve : le framework, l'infrastructure de test, le pipeline CI, les systèmes de données de test — du code de qualité production, revu par les développeurs en tant que pair.

Les deux testent. L'un est aussi responsable du code qui teste.

Beaucoup de tests unitaires rapides à la base, moins de tests API/intégration au milieu, peu de tests E2E/UI au sommet — parce que le coût, la lenteur et l'instabilité augmentent à mesure qu'on monte.

Inversée (le « cornet de glace ») : des centaines de tests UI, une couche API mince, peu d'unitaires — pipelines lents, rouges instables, échecs qui ne pointent nulle part, et une équipe qui cesse de faire confiance au vert. Le correctif, c'est descendre les vérifications, pas ajouter du matériel.

En couches, de bas en haut : config (par environnement, secrets injectés) ; drivers/clients (browser factory, client API) ; pages/composants pour la structure UI ; couche de données (builders/factories, seedées par API, parallel-safe) ; tests — scénarios minces uniquement ; reporting (artefacts à l'échec, publiés en CI). L'authentification gérée une fois, sous l'UI.

Puis défendez les choix : composition plutôt qu'héritage, setup API-first, isolation plutôt qu'état partagé — et ce que vous avez délibérément laissé de côté.

Descendez la confiance et découplez les équipes : de solides tests unitaires + de service par service en isolation (dépendances mockées) ; des tests de contrat entre chaque paire consommateur-fournisseur — la couche qui remplace la plupart des E2E inter-services ; un mince ensemble d'E2E de parcours critiques sur un environnement complet ; et du shift-right — canaries, monitoring, alerting comme partie de la stratégie, parce que la vérité de l'intégration vit en production.

L'anti-objectif : un staging géant où tous les services doivent être verts pour tester quoi que ce soit.

Trois capacités : création — factories/builders fabriquant des entités à la demande via API ou seeding direct (« un utilisateur avec une carte expirée » en un appel) ; isolation — données uniques par run, parallel-safe, détruites ou namespacées ; volume réaliste — jeux de données anonymisés à la forme de la production pour le volume, la migration et le travail de performance, rafraîchis selon un planning.

Règle un : les tests fonctionnels ne partagent jamais de données mutables. Règle deux : les données de production n'entrent jamais dans les systèmes de test sans anonymisation.

Du parallélisme, plus de l'honnêteté sur le mix. Le calcul à voix haute : si le test moyen dure 3 s, c'est 30 000 s de travail — ~50 workers pour 10 minutes. Donc : shard sur des workers (conteneurs, éphémères), équilibrez les shards par durée et non par nombre, rendez chaque test isolation-safe d'abord, séparez par couche (les unitaires en secondes restent locaux ; la tranche UI reçoit les workers), cachez les builds/deps, et échouez vite avec des résultats en direct.

Le déclic n'est jamais le matériel seul — ce sont des tests qui peuvent tourner n'importe où, dans n'importe quel ordre.

Deux publics, deux vues. Ingénieurs, par run : les échecs avec artefacts inline (trace, capture, logs), échec nouveau-vs-connu, durée, marqueurs d'instabilité, build/commit testé. Leads, dans le temps : tendances de taux de réussite et d'instabilité, dérive de la durée de suite, tests les plus lents, nombre et âge des quarantaines, corrélation avec les défauts échappés.

Chaque widget doit répondre à une question que quelqu'un pose vraiment — les tableaux de bord meurent de décoration.

Structurez à voix haute. Fonctionnel : aller-retour raccourcir → rediriger, alias personnalisés, doublons, URL invalides/malveillantes. Limites : URL unicode, URL énormes, liens expirés, comportement de collision à l'échelle. Non fonctionnel : latence de redirection (c'EST le produit), charge à lecture dominante (les lectures écrasent les écritures), disponibilité. Sécurité : abus d'open-redirect, énumération des codes courts, rate limits, injection de schéma javascript:.

Concluez par la priorisation : la justesse de la redirection et sa latence d'abord — c'est le seul travail du produit.

Vérifier que les attentes d'un consommateur envers l'API d'un fournisseur correspondent à ce que le fournisseur sert vraiment — sous forme de contrats exécutables (façon Pact), vérifiés dans les DEUX pipelines avant le déploiement. Le consommateur enregistre ce dont il a besoin ; le fournisseur rejoue et prouve que ça tient toujours.

Ça vaut le coup quand des équipes indépendantes déploient des services qui se parlent — c'est la couche qui attrape les changements cassants sans staging partagé. Excessif pour un monolithe ou quand une équipe possède les deux côtés.

La checklist complète : codes de statut, corps et schéma de réponse, erreurs avec messages utiles, authz (l'ID d'un autre utilisateur → 403), effets de bord persistés, idempotence, headers, latence.

Priorisé : 1) le contrat happy-path par endpoint — le smoke ; 2) auth/authz partout — les bugs catastrophiques les moins chers ; 3) les chemins d'erreur dont dépendent les consommateurs ; 4) données limites et idempotence ; 5) baselines de performance. L'argent et les permissions avant l'exhaustivité.

JWT : token expiré → 401, payload/signature falsifié → rejeté, attaque alg:none rejetée, bons claims imposés (rôles, audience, émetteur), expiration réellement honorée côté serveur.

OAuth2 : le flow de grant complet, rotation du refresh, imposition des scopes (un token à scope read ne peut pas écrire), la révocation révoque vraiment, redirect_uri strictement validé (le trou classique), paramètre state imposé (CSRF).

Le thème : ne testez pas que le login marche — testez que tout le RESTE est rejeté.

Une opération est idempotente si la faire deux fois a le même effet qu'une fois — GET/PUT/DELETE par conception, POST seulement si c'est ingénieré (clés d'idempotence).

Pourquoi les testeurs s'en soucient : les retries sont partout — les réseaux échouent, les utilisateurs double-cliquent, les queues redélivrent. Chaque retry contre une opération non idempotente est un potentiel double-débit, double-e-mail, commande en double. Le test : la même requête deux fois (puis en concurrence), affirmer exactement un effet.

Tous des doublures de test, des jobs différents. Stub : renvoie des réponses toutes faites — vous affirmez sur l'état de votre système. Mock : préprogrammé avec des attentes — l'assertion EST l'interaction (« charge() a-t-il été appelé une fois avec 50 $ »). Spy : la vraie chose (ou un stub) qui enregistre les appels pour inspection ultérieure. Fake : implémentation légère fonctionnelle — base en mémoire, passerelle de paiement factice.

Règle générale : stubbez les requêtes, mockez les commandes, fakez l'infrastructure.

Mockez ce que vous ne contrôlez pas ou ne pouvez pas vous permettre : API tierces, externes lents/instables, conditions d'erreur que vous ne pouvez pas déclencher à la demande, tout ce qui facture à l'appel. Utilisez la vraie chose pour ce que le test existe à vérifier : votre logique, vos requêtes, vos coutures d'intégration — avec les conteneurs rendant « réel mais jetable » bon marché.

Chaque mock est un petit mensonge sur le monde ; gardez quelque part une vérification d'intégration qui dit la vérité.

Un service simulé en cours d'exécution — WireMock/Mountebank/Hoverfly servant l'API d'une dépendance sur le réseau : avec état si besoin, latence injectable, partagé par n'importe quel consommateur quel que soit le langage. Le mocking vit dans votre processus de test et meurt avec lui.

Virtualisez quand : plusieurs équipes ont besoin de la même dépendance simulée, vous testez des applis déployées (pas juste du code), ou vous avez besoin d'injection de faute/latence au niveau du fil.

Charge : trafic attendu — tient-il les SLA en normal et en pic ? Stress : au-delà de la capacité — où casse-t-il, et casse-t-il gracieusement ? Endurance (soak) : charge normale pendant des heures/jours — fuites, épuisement des connexions, pourrissement lent. Pic (spike) : surtension soudaine — vente flash, notification push — et la récupération après.

Chacun répond à une question métier différente ; nommer laquelle est la partie senior.

Les moyennes cachent la souffrance : mille requêtes à 100 ms plus dix à 10 secondes font une moyenne de ~200 ms — ça semble bien, dix utilisateurs ont passé un sale moment. La latence est asymétrique, donc la moyenne suit la majorité chanceuse.

Utilisez les percentiles : p50 (typique), p95/p99 (la queue — vos vrais utilisateurs les plus malchanceux), plus le taux d'erreur et le débit ensemble. Les SLO sont écrits en percentiles pour exactement cette raison.

Suivez la requête à travers les couches, en mesurant à chacune : load balancer → appli (CPU ? threads ? GC ?) → pools de connexions (épuisés ?) → base (requêtes lentes, locks, index manquants) → appels externes → infrastructure (réseau, disque).

Corrélez QUAND la dégradation commence avec CE QUI sature à ce moment — les tableaux de bord ou les traces APM en font des minutes. Le goulot, c'est ce qui atteint son plafond en premier ; corrigez-le et relancez, parce qu'il y en a toujours un suivant.

Déterminisme et jetabilité : la même image épinglée tourne sur chaque laptop et worker CI — le « ça marche sur ma machine » meurt ; les environnements s'allument par run et disparaissent, donc pas de dérive, pas de pourrissement d'état partagé, et le parallélisme obtient une stack propre par worker.

Testcontainers est le pattern arrivé à maturité : de vrais Postgres/Kafka/Redis démarrés par le test lui-même, à la demande.

Étagé par vitesse de feedback. Sur PR (bloquant, <10 min) : lint, unitaires, tests de service avec deps conteneurisées, vérifs de contrat, le smoke pack E2E. Au merge → déploiement staging : intégration plus complète + parcours critiques, puis auto-promotion. Déploiement production : canary avec vérifs santé/SLO automatisées, auto-rollback. De nuit : régression complète, baseline de performance, scans de sécurité.

Principe : tout ce qui bloque doit être rapide ET digne de confiance — un seul flake dans la porte et les développeurs la contournent.

Tuez toute chose mutable partagée : données uniques par test (UUID/run-id, factories), pas de comptes partagés, pas de ports/fichiers/globals fixes, pas de dépendances d'ordre, état externe isolé ou namespacé par worker.

Puis prouvez-le : lancez en ordre mélangé et en parallèle en CI comme norme — les échecs qui apparaissent sont votre carte de couplage. La sûreté parallèle est une propriété qu'on impose, pas une option qu'on bascule.

Équilibrez par durée enregistrée, pas par nombre de tests : faites du bin-packing pour que chaque shard finisse ensemble — le temps mural de la suite est son shard le plus lent. Alimentez avec les données de timing des runs précédents, rééquilibrez continuellement, et gardez les shards assez déterministes pour déboguer.

Raffinements : mettez les instables hors du signal de timing, séparez les longs FICHIERS de test si le runner sharde par fichier, et surveillez la variance de fin-de-shard comme métrique de santé.

Parcourez le tableau une fois, en gardant un set des valeurs vues ; si la valeur courante est déjà dans le set, il y a un doublon. O(n) en temps, O(n) en espace — chaque élément vérifié une fois, opérations de set en O(1).

Énoncez les alternatives pour montrer l'éventail : trier d'abord → O(n log n) en temps mais O(1) d'espace supplémentaire (si en place) — le compromis qui vaut la peine d'être dit à voix haute. La force brute par paires est en O(n²) — nommez-la seulement pour la rejeter.

Solide sur l'ensemble de travail : tableaux, chaînes, hash maps/sets, listes, arbres de base ; deux pointeurs, fenêtre glissante, BFS/DFS au niveau facile-à-moyen ; et une aisance en big-O — parce que le code de framework a de vrais choix de performance dedans.

Pas nécessaire : le golf de programmation dynamique, les internes des arbres rouge-noir, les astuces de compétition. Le cadrage honnête : assez de DSA pour passer un screen développeur mid, appliqué surtout à des problèmes d'infra de test — parsing de logs, génération de données, diffing de résultats.

Une méthode visible : reformulez le problème et confirmez ; clarifiez entrées, cas limites, contraintes (trié ? vide ? taille ?) ; travaillez un petit exemple à la main ; énoncez la force brute et sa complexité, puis améliorez ; codez en narrant ; puis testez vous-même — cas normal, limite, vide — avant de déclarer terminé.

Ce dernier pas, sans qu'on le demande, est la signature QA, et les examinateurs le remarquent.

L'ensemble de travail : Page Object/Component (structure UI), Builder/Factory (données de test : aUser().withExpiredCard().build()), Facade (une API propre au-dessus d'un setup en désordre), Strategy (échanger les implémentations navigateur/env), Singleton — avec parcimonie (config ; dangereux pour les drivers en parallèle), Observer (listeners pour les artefacts à l'échec).

Les patterns résolvent la duplication et le coût du changement ; nommer quel problème chacun résout dans VOTRE framework est la réponse.

Directement, avec des sens à forme de test. S : un page object fait la structure UI OU le setup de données, jamais les deux ; un test vérifie un comportement. O : ajoutez un nouveau navigateur/env sans éditer chaque classe — factories et config. L : toute implémentation de votre interface client doit être interchangeable (réel vs fake). I : de petites fixtures ciblées plutôt que des god-helpers. D : les tests dépendent d'abstractions — une interface ApiClient — pas d'un câblage concret.

Le bénéfice est le même que dans le code de prod : les coûts de changement restent locaux.

Le prisme testabilité-et-risque que les développeurs survolent : chemins d'erreur (que se passe-t-il quand l'appel échoue — est-ce géré, loggé, remonté ?), entrées limites (null/vide/borne), observabilité (verra-t-on ça échouer en prod ?), testabilité (dépendances injectables, ou singletons câblés en dur ?), test-ids sur la nouvelle UI, et « quels tests existants ce changement invalide-t-il ? ».

La revue SDET n'est pas une police du style — c'est poser, plus tôt, les questions que la revue d'incident poserait.

Les développeurs — ils connaissent l'intention du code, les tests tournent avec leur build, et le feedback à la TDD ne marche qu'au moment de l'écriture. Des tests unitaires écrits par quelqu'un d'autre arrivent tard et testent des suppositions.

Le rôle du SDET : rendre ces tests BONS — les relire, pousser la couverture là où vit le risque, bâtir les harnais et les patterns, et tenir la ligne dans le pipeline. La propriété de la qualité est partagée ; la propriété des tests unitaires est celle de l'auteur.

Ligne : cette ligne s'est-elle exécutée ? Branche : les DEUX côtés de chaque if ont-ils tourné ? — plus strict, attrape le else non testé. Mutation : modifiez le code (inverser une comparaison, supprimer un appel) et voyez si un test échoue — mesurant si les tests ATTRAPERAIENT vraiment des bugs, pas si le code a tourné.

L'échelle de l'honnêteté : la ligne dit que le code s'est exécuté, la branche dit que les chemins se sont exécutés, la mutation dit que les tests peuvent détecter un changement. Seule la dernière mesure la QUALITÉ des tests.

Réorientez, ne refusez pas : la couverture comme KPI invite au jeu — des tests sans assertions atteignent n'importe quel chiffre — et les derniers 15 % (getters, glue, config) coûtent le plus tout en attrapant le moins.

Contre-proposez quelque chose de mesurable et d'honnête : couverture élevée sur les lignes changées par PR, spot-checks de mutation sur les modules critiques, tendance des défauts échappés, taux d'instabilité. Dites oui à l'objectif (la confiance), non au proxy (un seul pourcentage).

Des outils (PIT, Stryker, mutmut) sèment de petits changements de code — comparaisons inversées, appels supprimés, constantes modifiées — et lancent vos tests : un mutant que votre suite tue est bon ; un mutant survivant est une forme de bug que vos tests rateraient.

L'utiliserais-je ? Oui, chirurgicalement : modules critiques (argent, auth, tarification) selon un planning ou au changement — pas sur toute la suite en CI, parce que c'est lourd en calcul. C'est un outil d'audit, pas une porte.

Bloquant sur PR : build, vérifs lint/type, tests unitaires + de service, vérification de contrat, scan de sécurité sur les dépendances (échec sur CVE critiques connues), le smoke pack E2E, fil-piège de couverture-sur-lignes-changées. Observant, pas bloquant : régression complète, baselines de performance, scores de mutation — rapportés, tracés, actionnés, mais pas dressés entre un dev et un merge.

La discipline : une porte bloquante doit être rapide et digne de confiance ; chaque flake dedans dévalue la monnaie de tout le pipeline.

Au-delà de « ça a tourné » : justesse — comptes de lignes, checksums/agrégats et spot-diffs entre ancienne et nouvelle formes ; intégrité — contraintes, clés étrangères, rien d'orphelin ; le rollback — exécutez-le vraiment, ne faites pas que faire confiance à l'existence du script ; performance à l'échelle de production — une migration instantanée sur 10k lignes de staging peut verrouiller une table de 50M de lignes une heure ; et l'appli pendant la migration — ancien code contre nouveau schéma (ou le pattern expand/contract) pour des déploiements sans coupure.

Testez les garanties, pas juste la plomberie : les producteurs émettent les bons événements (schéma + contenu — consommez et affirmez) ; les consommateurs sont idempotents (redélivrez le même événement — exactement un effet) ; les hypothèses d'ordre tiennent au sein des partitions ; les échecs routent vers retries/DLQ plutôt que de disparaître ; et le lag sous charge reste sain.

L'asynchrone a besoin d'assertions asynchrones : poll-jusqu'à-cohérent avec timeouts, jamais sleep-et-espère. Testcontainers Kafka rend tout ça exécutable par-build.

La couche sous le pentesting est le job de la QA : authz sur chaque endpoint (l'ID d'un autre utilisateur → 403 — chasse à l'IDOR), gestion des entrées (payloads d'injection dans l'ensemble de test standard), coutures d'authentification (expiration, révocation, rate limits), hygiène des secrets (rien dans les logs, les URL ou le stockage client), scan de dépendances en CI, et headers de sécurité/flags de cookies comme vérifs automatisées.

Cadré comme conception de test : des cas d'abus à côté des cas d'usage, à chaque fonctionnalité.

La capacité du système à s'expliquer depuis ses sorties — logs, métriques, traces — pour poser de nouvelles questions à la production sans redéployer. Le monitoring surveille les modes de défaillance connus ; l'observabilité laisse déboguer les inconnus.

Elle change le test de trois façons : c'est une exigence testable (cette fonctionnalité émet-elle les événements/métriques dont on aurait besoin en incident ?), elle étend le test en production (canaries, portes de release basées SLO), et c'est un outil de débogage pour le système de test lui-même.

Ils séparent le déploiement de la release — ce qui déplace du test APRÈS le déploiement, derrière le flag : tester en production sans risque (flag activé pour les comptes de test), déployer progressivement en surveillant les métriques.

Nouvelles obligations : tester les deux états des flags conséquents (off doit rester sûr — c'est le rollback), guetter les interactions entre flags, garder un process d'hygiène des flags (les flags expirés sont des bugs latents), et savoir que le kill-switch marche — basculez-le vraiment.

Blue-green : deux environnements identiques ; déployez sur l'inactif, vérifiez, basculez le trafic — le rollback c'est rebasculer. Canary : nouvelle version sur une petite tranche (1–5 %), surveillez taux d'erreur/latence/métriques métier contre baseline, élargissez ou rollback.

Le rôle du test : définir les vérifs de santé qui gardent la promotion (automatisées, pas au feeling), smoker l'inactif/le canary avant le trafic, et vérifier le chemin de rollback lui-même — les rollbacks non répétés échouent quand on en a le plus besoin.

Un seul endpoint, des requêtes infinies — donc le test passe de « par endpoint » à par opération et par resolver : authz au niveau du champ (ce rôle peut-il voir CE champ — la fuite classique), limites de profondeur/complexité de requête (DoS par requête imbriquée), performance N+1 des resolvers, forme des erreurs (200 OK avec un tableau errors — vos assertions doivent lire le corps), et évolution de schéma (dépréciations au lieu de versioning).

Le changement mental : le schéma est une énorme surface ; les clients choisissent leur propre tranche.

Injecter délibérément de la panne — instances tuées, latence, dépendances coupées — pour vérifier que les promesses de résilience du système tiennent : les retries réessaient, les failovers basculent, les alertes alertent. Piloté par hypothèse et à rayon d'impact limité, pas du vandalisme.

L'utiliserais-je ? Oui, mis à l'échelle du contexte : injection de faute en staging pour chaque fonctionnalité de résilience (c'est juste du test), et des expériences de production contrôlées seulement une fois l'observabilité et le rollback matures. C'est la suite de tests des « -ilités » que tout le monde revendique et que personne ne vérifie.

Cadrez-le en risque contre risque — le coût du bug (impact × portée × contournement) contre le coût du correctif SI près de la release (risque de changement, périmètre de re-test, délai). Ajoutez la réversibilité : peut-on le désactiver par flag, hotfixer demain, ou est-ce gravé dans une release mobile pour des semaines ?

Puis mon vrai job : rendre ce compromis visible au responsable en chiffres clairs, recommander, et enregistrer la décision. La QA possède rarement la décision ; la QA possède toujours son honnêteté.

Les preuves avant les théories : tirez les artefacts CI (trace, capture, vidéo, logs) de plusieurs échecs et comparez-les — même étape à chaque fois, ou dispersé ? Puis reproduisez délibérément : lancez-le en boucle dans des conditions proches de la CI (headless, parallèle, mêmes ressources).

Pattern → hypothèse → correctif ciblé : même étape = course de timing là ; seulement-en-parallèle = état partagé ; étapes aléatoires = environnement/ressources. Mettez en quarantaine en attendant pour que l'équipe garde confiance au rouge — et vérifiez si c'est le PRODUIT qui court, pas le test.

Mesurez d'abord — rapport de timing, trouvez où vivent les heures. Puis par ordre de rendement : parallélisez (généralement le plus gros pas — nécessite un travail d'isolation) ; descendez les tests d'une couche (des vérifs UI qui sont vraiment des vérifs API/unitaires — souvent un tiers du temps d'exécution) ; tuez le setup dupliqué (login API vs 200 logins UI, fixtures partagées par worker) ; supprimez/fusionnez les tests redondants après un audit de couverture ; séparez par but (smoke bloquant vs profondeur de nuit) pour que la cible de 30 minutes s'applique à ce qui garde les merges.

Commencez là où la douleur est la plus forte et le gain le plus rapide : un smoke pack sur le chemin critique, en CI, semaine un — dix tests qui tournent à chaque build et attrapent visiblement des choses. Pas une odyssée de framework.

Puis grandissez par valeur démontrée : régression sur les zones qui mordent, couche API à mesure qu'elle se stabilise, enseignez en construisant (pairing, templates) pour que ce soit la capacité de l'équipe, pas votre fief — et rapportez les gains dans le langage de l'équipe : « attrapé avant le merge », « le test de release est passé de 3 jours à 1 ».

Séparez le déterministe du probabiliste. Déterministe (test normal) : le pipeline, l'extraction de features, les contrats d'API, les replis quand le modèle échoue ou expire. Probabiliste (nouvelle discipline) : des jeux de données de référence (golden) avec sorties attendues, des métriques de qualité avec seuils au lieu d'asserts exacts (précision ≥ X sur le jeu d'éval), des vérifs de régression entre versions de modèle, une évaluation par tranche biais/limite, et du monitoring en production pour la dérive.

Le changement d'état d'esprit : de « la réponse est-elle correcte » à « la distribution de qualité est-elle acceptable — et stable ».

Jours 1–30, apprendre avant de toucher : livrez quelque chose de petit mais réel (un flake corrigé, un test smoke manquant) tout en cartographiant les chemins d'argent du produit, la vraie douleur de l'équipe (demandez à tous « qu'est-ce qui casse le plus ? »), et le parc de tests existant honnêtement.

31–60, gains ciblés : attaquez la douleur principale — d'habitude instabilité, temps d'exécution, ou un trou de couverture — avec un avant/après mesurable. 61–90, structure : le plan d'amélioration avec les empreintes de l'équipe dessus, des standards convenus en revue, et une métrique en tendance publique (taux d'instabilité, temps de porte PR).

Par les résultats, pas la taille : défauts échappés en baisse (l'étoile polaire — les bugs que la production trouve et que la suite aurait dû attraper), ratio de détection de défauts (quelle part des vrais bugs la suite attrape en premier), taux d'instabilité proche de zéro (le rouge est cru), vitesse qui garde sans être contournée, et des spot-checks de mutation prouvant que les tests peuvent vraiment échouer.

Le résumé inconfortable : la qualité d'une suite se mesure à ce qui passe à travers, et la plupart des équipes ne regardent jamais.

Amenez-en une vraie, structurée : ce qui a échappé, le manque spécifique qui l'a permis (pas « pression de temps » — le vrai trou dans la conception du test), le rayon d'impact et le nettoyage, et le correctif systémique — ce qui a changé pour que la CLASSE de bug soit couverte, pas juste l'instance.

Notée presque entièrement sur l'appropriation : une phrase d'honnêteté sans blâme sur le manque, trois sur le jugement qui a suivi.

Consolidation vers le haut : l'exécution de routine et l'écriture d'artefacts se font automatiser (dernièrement accéléré par l'IA), tandis que le cœur durable grandit — stratégie de test et jugement du risque, ingénierie qualité à travers le pipeline, tester les nouvelles choses difficiles (fonctionnalités ML, systèmes événementiels), et être la personne qui sait REVOIR des tests générés par machine plutôt que tout écrire à la main.

Préparation, concrètement : profondeur d'ingénierie (le chemin SDET lui-même), aisance en production/observabilité, et utiliser l'IA comme outil de brouillon tout en possédant la couche de jugement qu'elle ne peut pas faire.

Ça tue le « ça marche sur ma machine ». Docker empaquette l'environnement de test — version du navigateur, drivers, dépendances, config — dans une image qui tourne à l'identique sur votre laptop, celui d'un collègue, et en CI. Même image, même résultat.

Avant lui, une suite passait en local et échouait en CI à cause d'une version de Chrome ou d'une bibliothèque manquante, et vous y perdiez une journée. Avec Docker, le runner et votre machine exécutent l'environnement identique au bit près, donc une différence d'environnement cesse d'être un suspect.

Utilisez une image préconstruite qui a déjà le navigateur et le driver — les images officielles Selenium (selenium/standalone-chrome) ou Playwright — pour ne pas installer un navigateur à la main. Lancez en headless, et montez un volume pour extraire captures, vidéos et traces après le run.

Le piège que tout le monde rencontre : Chrome crashe dans un conteneur parce que le /dev/shm par défaut est trop petit. Soit vous l'augmentez (--shm-size=2g), soit vous lancez avec --disable-dev-shm-usage. Ne pas connaître celui-là est le signe de quelqu'un qui n'a jamais vraiment conteneurisé une suite de navigateur.

Compose démarre tout un environnement multi-services depuis un seul fichier — l'appli sous test, sa base, une file de messages, un nœud Selenium — tous mis en réseau ensemble, en une commande. Vos tests obtiennent une vraie stack isolée au lieu de mocks ou d'un staging partagé pour lequel tout le monde se bat.

Le bénéfice est une ardoise propre à chaque run : montez-la, seedez les données, testez, démontez-la. Pas d'état résiduel, pas de « quelqu'un a changé le staging », et la même stack en CI qu'en local. C'est comme ça qu'on rend les tests d'intégration reproductibles.

Selenium Grid (souvent lancé en conteneurs Docker) est votre propre hub avec des nœuds de navigateur — vous le contrôlez, c'est bon marché à l'échelle, et c'est privé. Une grid cloud (BrowserStack, Sauce Labs) loue des navigateurs et de vrais appareils à la demande — pas d'infrastructure à maintenir, une énorme matrice navigateur/OS, mais un coût à la minute.

Règle empirique : Grid auto-hébergée pour des runs parallèles lourds et réguliers où vous voulez le contrôle et un coût bas ; grid cloud quand il vous faut de vrais appareils, des combinaisons navigateur/OS obscures, ou que vous ne voulez pas gérer d'infrastructure. Beaucoup d'équipes utilisent les deux — Grid pour le gros, cloud pour la longue traîne de compatibilité.

Le job CI lance vos tests à l'intérieur de la même image épinglée que vous utilisez en local, donc le navigateur, les drivers, le runtime du langage et les bibliothèques sont identiques au bit près partout. Un run vert aujourd'hui se reproduit le mois prochain parce que l'environnement est gelé dans l'image, pas assemblé à neuf à chaque fois.

C'est la différence entre un pipeline instable et un digne de confiance : sans ça, la CI installe la « dernière » version de tout et un bump amont silencieux vous casse du jour au lendemain. Épinglez le tag de l'image (pas :latest) et l'environnement cesse d'être une variable.

Les environnements diffèrent quelque part où le conteneur le cache. Vérifiez les écarts évidents : versions navigateur/driver gravées dans l'image vs installées sur la VM, headless vs headed, mémoire disponible et /dev/shm, fuseau horaire et locale, et différences de système de fichiers/permissions.

La méthode est de réduire l'écart : lancez la version exacte du navigateur de la VM en headless en local, ou mieux, lancez les tests dans le même conteneur sur la VM. Reproduire l'écart bat théoriser — la plupart des bugs « seulement sur la VM » sont une version ou une limite de ressource que le conteneur avait discrètement standardisée.

Rapide et ciblé à chaque PR : tests unitaires, une suite smoke, linting — des minutes, parce que ça garde le merge et que les gens attendent. La régression complète et la matrice multi-navigateurs tournent de nuit ou au merge sur main, où un temps d'exécution plus long est acceptable. Les vérifs plus lourdes et lentes — E2E complet, performance, scans de sécurité — vont sur un planning ou avant release.

Le principe est une vitesse de feedback adaptée au rayon d'impact : ce qui bloque un développeur doit être rapide ; ce qui peut prendre une heure tourne là où personne n'attend. Mettre la suite de deux heures à chaque push est comment les équipes apprennent à ignorer la CI.

Parallélisez d'abord — répartissez les tests sur des runners ou des threads ; une suite qui tourne en série en 40 minutes peut finir en 5 sur 8 workers. Puis descendez le travail dans la pyramide : si un test API ou unitaire peut le couvrir, ne dépensez pas un test UI dessus. Séparez les vérifs rapides (par-PR) des lentes (de nuit). Cachez les dépendances et les couches Docker pour ne pas reconstruire le setup à chaque run.

Et corrigez les tests instables plutôt que de les réessayer — les reruns cachent la lenteur et doublent le coût. Le but est que la porte qu'un développeur attend reste sous quelques minutes à mesure que la suite grandit.

Mesurez-le, puis mettez-le en quarantaine avec une trace écrite — ne réessayez pas en bloc. D'abord lancez-le assez pour obtenir un vrai taux d'échec, pour que « instable » soit un chiffre, pas un ressenti. Puis marquez-le (un tag de quarantaine qui le sort de la porte de merge), ticketez-le, et donnez-lui un propriétaire, le jour même.

L'anti-pattern est de réessayer automatiquement chaque échec. Les retries cachent le flake, coûtent du temps d'exécution, et apprennent à l'équipe que le rouge veut dire « relance-le » — donc une vraie régression se fait ignorer avec le reste. La quarantaine garde la porte honnête pendant que le correctif est en file ; elle ne supprime pas la couverture en silence.

Chaque run reçoit des données propres et isolées qu'il possède — seedées via l'API ou une fixture au début, démontées après — jamais une dépendance à un enregistrement partagé maintenu à la main. Les environnements sont provisionnés de façon reproductible (une stack Compose ou un namespace éphémère), pas un seul staging pour lequel chaque pipeline se bat.

Les secrets — clés d'API, identifiants de DB — viennent du magasin de secrets de la CI injectés au moment du run, jamais committés. Tout l'intérêt est que deux runs, ou deux jobs parallèles, ne peuvent pas corrompre l'état l'un de l'autre ni fuiter des identifiants.

Il répond à « qu'est-ce qui a cassé et pourquoi » sans ouvrir un terminal. Comptes de réussite/échec et durée en haut, puis chaque échec avec son assertion, et les artefacts qui permettent de le déboguer — capture, vidéo ou trace, et logs — attachés, pas décrits. Des tendances dans le temps signalent un test qui devient lentement plus instable.

Le test est de savoir si un coéquipier peut trier un build rouge depuis le seul rapport. S'il doit relancer en local pour comprendre un échec, le rapport a échoué. Publiez-le là où l'équipe regarde déjà — la PR, le tableau de bord CI — pas un fichier que personne n'ouvre.

En couches, chacune avec un job. Une couche core/util (setup du driver, attentes, config). Une couche page/service qui enveloppe l'appli (Page Objects pour l'UI, une couche client pour l'API) pour que les sélecteurs et les endpoints vivent en un seul endroit. Une couche de test qui se lit comme une intention et affirme. Les données gérées par fixtures/factories, la config depuis l'environnement, les résultats dans un rapport, le tout lancé en CI.

Le test que j'appliquerais : un changement d'UI touche une seule classe de page, un nouvel endpoint est une seule méthode de client, et un test énonce ce qu'il vérifie, pas comment. Si un changement de sélecteur ondule dans cinquante tests, le découpage en couches est mauvais.

Utilisez les trois pour ce à quoi chacun est bon. Les fixtures donnent à un test son cycle de vie setup/teardown (une session connectée, un fichier temporaire). Les factories construisent des objets avec des valeurs par défaut sensées et seuls les champs qui importent au test surchargés — makeUser(role="admin") — pour que les tests ne soient pas enfouis sous du boilerplate. Le seeding met les données dans le système en amont, via l'API ou la DB, pour qu'un test ait de quoi agir.

La règle à travers les trois est l'isolation : un test crée ce dont il a besoin et nettoie, pour que rien ne dépende d'un enregistrement partagé. C'est ce qui garde la suite parallel-safe et répétable.

La config (URL de base, timeouts, quel environnement) vient de l'extérieur du code — variables d'environnement ou fichiers de config par-environnement que le run sélectionne — jamais codée en dur, pour que la même suite tourne contre dev, staging ou un conteneur en changeant une seule entrée. Les secrets (clés d'API, identifiants) viennent d'un magasin de secrets ou de variables d'env injectées par la CI au moment du run, et ne touchent jamais le repo.

Le test : passer de local à CI à un nouvel environnement est un changement de config, pas un changement de code. Et un grep du repo pour un vrai identifiant ne renvoie rien.

Le Page Object Model associe une classe à chaque page/composant, tenant ses sélecteurs et ses actions — simple, universellement compris, et le bon défaut. Sa faiblesse se voit à l'échelle : les classes de page enflent, et les interactions réutilisables se dupliquent entre les pages.

Le screenplay (des acteurs accomplissant des tâches) et les modèles à base de composants composent de petites interactions réutilisables au lieu de classes à taille de page — plus flexibles pour de grandes suites, mais plus de concepts à apprendre et plus faciles à sur-ingénierer. Réponse honnête : le POM pour la plupart des équipes ; ne saisissez les alternatives que quand le POM peine visiblement sous la duplication et les classes de page géantes.

Charge — trafic attendu, tient-il le coup. Stress — au-delà de la limite, où et comment casse-t-il. Pic (spike) — une surtension soudaine, survit-il et récupère-t-il. Endurance (soak) — charge soutenue sur des heures, fuit-il de la mémoire ou se dégrade-t-il.

Chacun répond à une question différente : la charge prouve le jour normal, le stress trouve le plafond, le pic teste un lancement ou une vente, l'endurance attrape la fuite lente qui n'apparaît qu'après quatre heures. Nommer lequel un scénario réclame est le signe que vous l'avez fait, pas juste lu.

Le débit (requêtes/sec), le taux d'erreur sous charge, l'usage des ressources (CPU, mémoire), et les percentiles de latence — p95 et p99, pas la moyenne. Les moyennes cachent la douleur : une moyenne de 200 ms peut vouloir dire que 5 % des utilisateurs attendent 4 secondes, et ce sont souvent vos sessions de plus grande valeur.

Dire « temps de réponse moyen » comme métrique phare vous marque comme junior. Le p99 est l'expérience de vos utilisateurs réels les plus mal servis, et c'est là que vivent les SLA et les clients perdus.

Un Thread Group définit les utilisateurs virtuels et la montée en charge (ramp-up). À l'intérieur, les Samplers font les requêtes (HTTP), les Config Elements tiennent les données partagées (URL de base, un CSV de données de test), les Assertions vérifient que les réponses restent correctes sous charge, et les Listeners collectent les résultats. Les Timers ajoutent un temps de réflexion réaliste entre les requêtes.

La structure imite une vraie session d'utilisateur : montez les utilisateurs progressivement (pas tous d'un coup), donnez à chacun des données uniques pour qu'ils ne martèlent pas un seul enregistrement, affirmez que les réponses sont encore valides — un 500 rapide n'est pas un succès — et enregistrez les percentiles, pas juste les moyennes.

À partir de données réelles, pas d'une devinette. Tirez le trafic de production — pic d'utilisateurs simultanés, requêtes par seconde, l'heure la plus chargée — et modelez le test dessus, puis ajoutez de la marge (testez à 1,5–2× le pic) pour prouver qu'il y a du mou. Pour un lancement sans historique, estimez depuis les chiffres attendus du marketing et testez au-dessus.

Un test de charge à un « 1000 utilisateurs » arbitraire ne prouve rien si votre vrai pic est 80 ou 8000. Le chiffre doit remonter à la réalité, et le rapport devrait énoncer quel scénario réel il représente.

D'abord, écartez le test lui-même — un générateur de charge sous-dimensionné ou un réseau lent sur la machine JMeter ressemble exactement à un serveur lent. Puis corrélez : surveillez CPU, mémoire, DB et thread pools du serveur pendant que la charge tourne, et voyez lequel sature en premier. Celui qui atteint 100 % pendant que les autres sont inactifs est votre goulot.

Coupables courants : la base de données (requêtes lentes, index manquant, pool de connexions épuisé), puis le CPU, puis la mémoire/GC. L'observabilité pendant le run bat la devinette — la métrique qui plafonne à son plafond nomme la couche à corriger.