Le premier mois d’un mandat de SDET principal ne devrait pas se mesurer au nombre de tests ajoutés. Une suite qui grandit peut rendre un système de livraison fragile plus coûteux sans améliorer ses décisions. Les premiers travaux doivent montrer où se situent les risques, quels signaux méritent confiance et qui maintiendra le système.
La séquence suivante est un cadre de planification. Elle ne garantit pas que toute organisation puisse terminer ces travaux en trente jours. Les restrictions d’accès, la complexité du produit et la disponibilité des parties prenantes influencent le rythme. L’essentiel est que chaque activité produise des éléments utiles à la décision suivante.
Jours 1 à 7 : comprendre la réalité d’une livraison
Suivez un changement récent, de l’intention produit jusqu’à la production. Comparez le processus documenté au travail réellement effectué. Qui a précisé les critères d’acceptation? Choisi les tests? Analysé les échecs? Approuvé les exceptions? Observé le déploiement?
Examinez un petit échantillon volontairement varié : une livraison ordinaire, une autre marquée par un défaut ou un incident, et une livraison retardée par la validation. Cet échantillon sert à faire émerger des questions, non à établir une représentativité statistique. Repérez les transferts de responsabilité, les incertitudes répétées et les tâches qui reposent sur la mémoire d’une seule personne.
Rencontrez les responsables de l’ingénierie, du produit et de l’exploitation. Posez des questions concrètes :
- Quel comportement rendrait la prochaine livraison inacceptable s’il échouait?
- Quelles preuves soutiennent actuellement ce comportement?
- Quels échecs de pipeline sont habituellement relancés sans analyse?
- Qu’est-ce qui ne peut être vérifié que manuellement, et pourquoi?
- Qui peut accepter un risque connu?
- Que se passe-t-il s’il faut annuler le déploiement?
Produisez une carte courte du processus de livraison et un premier registre des risques. Pour chaque risque, indiquez le comportement concerné, les conséquences possibles, les preuves disponibles, la lacune et le responsable probable. Faites valider cette lecture par les personnes qui effectuent le travail avant d’en tirer un programme d’amélioration.
Jours 8 à 14 : établir un état de référence des signaux
Examinez l’automatisation comme un système en exploitation, pas seulement comme du code. Regardez la fréquence des exécutions, les causes d’échec, la préparation des données, les hypothèses d’environnement, les éléments de diagnostic et les responsabilités. Exécutez un sous-ensemble représentatif localement et dans le pipeline. Les différences peuvent révéler des dépendances absentes des diagrammes.
Distinguez les défauts du produit, les défauts de test, les problèmes d’infrastructure et les échecs non résolus. Conservez le résultat à la première exécution : une réussite après reprise est un signal différent. La documentation de Playwright sur les reprises distingue les tests qui réussissent d’emblée de ceux qui échouent puis réussissent lors d’une reprise. Gardez cette distinction dans les rapports.
Choisissez des mesures qui éclairent des décisions : temps nécessaire pour identifier une cause, catégories d’échec récurrentes, effort manuel sur un parcours critique ou ancienneté des tests en quarantaine. Définissez le dénominateur, la période d’observation et la source. Sans ces précisions, une comparaison entre livraisons peut devenir trompeuse.
Présentez un état de référence accompagné de ses limites. Quelques exécutions ne suffisent pas à démontrer une fiabilité durable. Elles doivent toutefois permettre de choisir une intervention et d’observer si elle apporte une amélioration utile.
Jours 15 à 21 : démontrer une amélioration ciblée
Choisissez un parcours critique associé à un problème délimité et à un responsable disponible. Il peut s’agir de données de test peu fiables, d’une frontière API importante sans vérification utile ou d’un échec de pipeline trop pauvre en informations pour être diagnostiqué.
Définissez la question avant de commencer. Si le problème concerne le diagnostic, demandez-vous si un échec expose désormais la requête, la trace ou l’état des données utiles. S’il concerne les données partagées, vérifiez que des exécutions parallèles peuvent fonctionner indépendamment. Cela évite de faire d’un nouveau framework la réponse automatique à chaque difficulté.
Réalisez une tranche complète mais limitée : le test ou l’amélioration du diagnostic, son exécution en CI, les éléments de preuve, la responsabilité et les consignes de maintenance. Ajoutez un cas négatif qui démontre que le contrôle échoue pour la bonne raison. Un test qui réussit toujours ne prouve pas qu’il protège le produit.
Faites revoir ce travail par les personnes qui le maintiendront. Notez ce qui a compliqué l’intervention : accès à l’environnement, frontières produit fragiles, observabilité insuffisante ou exigences ambiguës. Ces contraintes doivent apparaître dans la feuille de route.
Jours 22 à 30 : établir les règles de fonctionnement
L’amélioration doit trouver sa place dans le quotidien de l’équipe. Convenez du moment où le test s’exécute, de ce qui bloque une fusion ou un déploiement, de la personne qui analyse et de la façon de consigner une exception. Le rôle principal clarifie les responsabilités sans devenir le point de passage obligatoire de chaque livraison.
Définissez une politique de quarantaine : responsable, motif, preuve de remplacement et date de révision. Une quarantaine sans chemin de retour peut supprimer progressivement la couverture tout en donnant l’impression que la suite reste saine.
Établissez une revue légère de préparation à la mise en production. La grille de préparation peut aider les équipes produit, ingénierie et exploitation à discuter des preuves plutôt que du nombre de tests. Adaptez-la au produit réel. Une nouvelle réunion n’est pas nécessaire si le processus existant peut accueillir la décision.
Quels éléments devraient exister après le premier mois?
Les éléments utiles comprennent une carte des risques et du processus, un état de référence défini, une amélioration technique revue, des règles de responsabilité et une feuille de route priorisée. Gardez-les assez concis pour être utilisés. Un rapport que personne ne peut relier au prochain sprint constitue un transfert incomplet.
Organisez la feuille de route entre stabilisation immédiate, travaux d’ingénierie durables et autonomie de l’équipe. Une première période peut viser le diagnostic des échecs, la suivante une frontière risquée, puis la réduction de la dépendance à un spécialiste. Les preuves doivent orienter ces priorités, pas le calendrier seul.
Invitez le responsable de l’ingénierie à remettre le plan en question : que cessera-t-on de faire, quelle dépendance peut bloquer le travail et qui maintiendra le résultat? Rendez ces réponses visibles avant de promettre un échéancier.
Une évaluation de l’ingénierie de la qualité permet d’établir ce point de départ. Selon les constats et la capacité de l’équipe, la suite peut être réalisée à l’interne, prendre la forme d’un projet ciblé ou d’un accompagnement par un SDET principal intégré.