Ingénieur QA

J'automatise tout ce qui est répétitif, stable et à forte valeur à vérifier à chaque build : les parcours utilisateurs critiques comme la connexion, le paiement ou la saisie principale de données. Ces tests vont dans ma suite Selenium ou Playwright et tournent à chaque pull request. Je garde les tests manuels pour tout ce qui est nouveau, très visuel, ou susceptible de changer dans le sprint suivant, car automatiser une fonctionnalité encore en itération est un effort perdu. Je réserve aussi les tests manuels aux sessions exploratoires, où j'essaie volontairement de casser le produit d'une façon qu'un test scripté ne penserait jamais à tenter. Une règle simple que j'utilise : si je pense devoir exécuter la même vérification plus de cinq fois sur la durée de vie d'une fonctionnalité, cela vaut la peine de l'automatiser. Je révise la suite automatisée chaque trimestre pour retirer les tests des fonctionnalités supprimées ou trop modifiées.

Je commence par lire les spécifications et signaler tout ce qui est ambigu avant d'écrire le moindre cas de test, car des exigences floues produisent des tests flous. Je cartographie d'abord le chemin nominal de la fonctionnalité, puis je liste les cas limites : états vides, longueurs maximales de saisie, utilisateurs concurrents et limites de permissions. Je regroupe les cas de test par niveau de risque, en priorisant tout ce qui touche aux paiements, à l'authentification ou à la perte de données. J'inclus des cas positifs et négatifs, et je note lesquels sont candidats à l'automatisation par rapport aux vérifications manuelles ponctuelles. Avant l'exécution, je partage le plan avec le développeur qui a construit la fonctionnalité, car il connaît souvent un cas limite auquel je n'ai pas pensé. J'intègre aussi une passe de régression couvrant les fonctionnalités adjacentes qui partagent du code avec la nouvelle. Une fois les tests lancés, je suis les résultats dans Jira pour que la couverture soit visible par toute l'équipe.

Un bon rapport de bug répond à trois questions avant même que le développeur les pose : qu'avez-vous fait, qu'attendiez-vous, et que s'est-il réellement passé. J'inclus des étapes de reproduction précises et numérotées, l'environnement (navigateur, système d'exploitation, numéro de build), et une capture d'écran ou un court enregistrement vidéo dès que le bug est visuel. Je joins les logs ou erreurs console pertinents plutôt que de les décrire de mémoire. J'indique toujours la sévérité du point de vue de l'utilisateur, pas seulement la sévérité technique : un bouton cassé sur une page d'administration rarement utilisée n'a pas la même priorité qu'un bouton de paiement cassé. J'évite les formulations vagues comme 'ça plante parfois' et je précise plutôt le taux de reproduction, par exemple '8 tentatives sur 10'. Si je ne parviens pas à reproduire le bug de façon fiable, je le dis explicitement plutôt que de laisser penser qu'il est reproductible à cent pour cent. Un rapport clair fait gagner vingt minutes d'allers-retours au développeur.

Je maintiens une suite de régression principale qui couvre les parcours utilisateurs critiques, et je l'exécute à chaque candidat de mise en production, automatisée autant que possible pour ne pas ralentir l'équipe. Pour les zones qui changent souvent, je tiens une cartographie des risques qui indique quelles fonctionnalités partagent des composants ou des modèles de données avec la zone modifiée, afin de savoir quoi vérifier même si ce n'était pas directement touché. Je m'appuie sur la suite automatisée pour la largeur de couverture et je réserve le temps de régression manuelle aux zones explicitement mentionnées dans les notes de version. Quand une version est importante, je priorise la régression autour de tout ce qui touche au revenu ou à l'accès au compte en premier, car ce sont les zones où un bug manqué coûte le plus cher. Je garde aussi la suite de régression elle-même sous revue, en retirant les tests des fonctionnalités obsolètes pour qu'elle reste rapide et pertinente plutôt que de grossir indéfiniment.

Nous étions sur le point de livrer un parcours de mise à niveau d'abonnement, et toute l'équipe avait testé le chemin standard : gratuit vers payant, avec un compte de test neuf. Pendant une session de tests exploratoires, j'ai essayé de mettre à niveau un compte ayant déjà un abonnement annulé mais encore dans sa période de grâce. La mise à niveau semblait réussir dans l'interface, mais le backend créait un enregistrement d'abonnement dupliqué au lieu de réactiver l'existant, ce qui aurait facturé le client deux fois au renouvellement. Je l'ai trouvé parce que j'ai délibérément testé un état de compte que personne n'avait configuré auparavant, plutôt que le seul scénario de compte propre prévu dans le plan de test. J'ai signalé le bug comme bloquant avec l'état de compte exact nécessaire pour le reproduire, et l'équipe a repoussé la livraison d'un jour pour corriger la logique de facturation. Cela m'a confirmé que les plans de test construits uniquement autour du chemin nominal manquent les états de compte que les vrais utilisateurs ont après des mois d'usage.

J'ai signalé un bug où les résultats de recherche s'affichaient dans le mauvais ordre pour certaines combinaisons de filtres. Le développeur a fermé le ticket en 'fonctionne comme prévu', arguant que la logique de tri était techniquement correcte. Je suis retourné voir le document de spécifications et j'ai trouvé que le texte original indiquait explicitement que les résultats devaient trier par pertinence d'abord, puis par date, ce que le code ne faisait pas. Plutôt que de débattre sur Slack, j'ai enregistré une courte capture d'écran montrant l'écart à côté du texte de la spec, et j'ai rouvert le ticket avec les deux pièces jointes. Nous avons eu un appel de cinq minutes où il a reconnu que l'intention avait été mal comprise pendant l'implémentation. J'essaie de garder ces conversations centrées sur l'exigence documentée plutôt que sur mon opinion personnelle, car cela rend le désaccord factuel et rapide à résoudre. Le correctif est sorti dans le patch suivant, et nous avons ajouté un test de régression spécifique pour cette combinaison de filtres.

Un email de confirmation de paiement est parti avec le mauvais symbole monétaire pour un petit nombre de clients internationaux. Il est passé les tests parce que nos comptes de test étaient tous configurés avec une seule région par défaut, donc le bug de formatage de devise ne s'est jamais déclenché en QA. Le support client l'a signalé en quelques heures, et nous avons corrigé la logique de formatage et renvoyé des emails corrigés aux utilisateurs concernés le jour même. Dans le post-mortem, j'ai réalisé que nos données de test ne reflétaient pas la répartition réelle de notre base d'utilisateurs, qui incluait alors plusieurs régions lancées récemment. J'ai constitué un ensemble de comptes de test couvrant nos cinq principaux marchés et ajouté le formatage des devises à la suite de régression principale pour qu'il tourne à chaque version touchant la facturation ou les emails. Cela a changé ma façon de penser les données de test en général : la diversité réaliste des comptes compte autant que la couverture des cas de test.

Pour l'automatisation d'interface, j'ai utilisé Selenium et plus récemment Playwright, et je préfère Playwright pour les nouveaux projets grâce à son mécanisme d'attente intégré, qui réduit les tests instables qui plombaient une grande partie de notre ancienne suite Selenium. Pour les tests d'API, j'utilise Postman pour le travail exploratoire et les vérifications rapides, et j'écris des tests d'API automatisés avec un framework comme REST Assured ou l'API de requêtes de Playwright quand ils doivent tourner en intégration continue. Pour le suivi des bugs et des cas de test, j'ai surtout travaillé avec Jira, avec les cas de test dans Xray ou dans un tableur léger selon la maturité de l'équipe. Je choisis les outils en fonction de l'expertise déjà présente dans l'équipe, sauf raison technique claire de changer, car le changement d'outil a un vrai coût en temps de montée en compétence. Quand je propose un nouvel outil, je lance d'abord un petit pilote sur une zone de fonctionnalité plutôt que de migrer toute la suite d'un coup.

Je pars de la spécification ou du contrat d'API, que ce soit un document OpenAPI ou un accord partagé avec le développeur backend, et j'écris les cas de test directement contre ce contrat. Avec Postman ou un framework automatisé, je teste d'abord le chemin nominal : des entrées valides renvoyant le code de statut et la forme de réponse attendus. Ensuite je teste les cas limites : champs obligatoires manquants, types de données invalides, valeurs limites, et requêtes non autorisées ou non authentifiées. Je vérifie que les réponses d'erreur renvoient des messages utiles et des codes de statut corrects, pas juste un 500 générique. Je teste aussi l'idempotence quand c'est pertinent, par exemple en confirmant qu'appeler deux fois un endpoint de paiement avec le même identifiant de requête ne crée pas de double facturation. Une fois la suite de test solide contre le contrat, je la garde dans le pipeline d'intégration continue pour que tout changement backend qui casse le contrat soit détecté immédiatement, bien avant que l'équipe front-end n'y touche.

Je découpe la suite en niveaux selon la vitesse et le niveau de confiance. Les tests unitaires et les tests d'API rapides tournent à chaque commit et doivent passer avant qu'une fusion soit autorisée. Une suite de smoke tests couvrant les parcours critiques tourne à chaque pull request contre un environnement de staging, généralement en moins de dix minutes. La suite de régression complète, plus lente et avec une couverture d'interface plus large, tourne chaque nuit ou avant qu'un candidat de version soit créé, pas à chaque commit, car cela ralentirait trop l'équipe. Je configure le pipeline pour faire échouer le build en cas d'échec d'un smoke test, mais je signale seulement les échecs de régression pour revue sans bloquer automatiquement, car un test instable dans une grande suite ne devrait pas bloquer une version à lui seul. Je suis aussi les tests instables séparément et je les mets en quarantaine jusqu'à ce qu'ils soient corrigés, pour que l'équipe ne perde pas confiance dans la suite en voyant le même faux échec se répéter.