Disposer d'un grand nombre de tests ne servait à rien si chaque échec entraînait l'ouverture d'une nouvelle enquête

Directeur de l'ingénierie

La plateforme du client comptait environ 1 100 tests automatisés, mais les équipes d'ingénieurs avaient cessé de faire confiance à cette suite. a1qa a été mandatée pour évaluer un sous-ensemble bien défini de 420 tests couvrant les flux critiques du commerce électronique, documenter une décision de conservation, de remplacement ou de suppression pour chaque test, et démontrer que l'ensemble ainsi obtenu pouvait étayer les décisions de déploiement.

El desafío

Le sous-ensemble critique présentait un taux de tests instables (flaky tests) de 18 %. De plus, 24 % des défaillances signalées ne correspondaient pas à des défauts reproductibles du produit. Des sélecteurs obsolètes, une logique de préparation dupliquée, des données incohérentes et une classification déficiente des erreurs obligeaient les ingénieurs à répéter les exécutions et à rechercher les sources de bruit avant de pouvoir évaluer le risque réel pour le produit.

Les tâches de maintenance et les réexécutions mobilisaient environ 45 heures d'ingénierie par semaine. Seules 52 % des exécutions de tests d'intégration se terminaient dans le délai convenu de 90 minutes et sans nécessiter de réexécution. La prise de décision concernant les tests de régression pour le périmètre sélectionné nécessitait environ deux jours ouvrés, ce qui limitait le domaine du produit à deux livraisons planifiées par mois.

Le client avait besoin d'éléments clairs lui permettant de déterminer quels éléments restaient valables, lesquels devaient être modernisés et lesquels il était plus économique de remplacer.

En l'espace de 12 semaines, a1qa est passée de la phase d'évaluation à la mise en œuvre d'un projet pilote grâce à une approche structurée de reprise et de stabilisation. L'équipe était composée de 3 ingénieurs en automatisation, d'un architecte senior en ingénierie qualité et d'un support DevOps à temps partiel.

Le projet a débuté par l'analyse des défaillances à travers de multiples exécutions répétées, l'examen de la structure du code et de ses dépendances, ainsi que la distinction entre les tests instables, les défaillances liées à l'environnement, les problèmes liés aux données et les défauts reproductibles du produit. Chacun des 420 tests inclus dans le périmètre critique a fait l'objet d'une décision de maintien, de remplacement ou de retrait, étayée par des critères techniques et économiques.

Après avoir stabilisé 170 tests dont l'objectif métier et l'architecture restaient valables, les ingénieurs en assurance qualité ont amélioré les sélecteurs, les assertions, les délais d'attente, la préparation des données et les composants réutilisables, tout en préservant la traçabilité par rapport aux parcours critiques du client.

Par la suite, l'équipe a remplacé 150 tests qui ne pouvaient pas être réparés de manière rentable. L'IA a été utilisée pour faciliter les tâches répétitives de préparation et de conversion de code, sur la base de scénarios préalablement approuvés. Les ingénieurs chargés de l'assurance qualité ont appliqué les conventions du framework, vérifié la logique métier et écarté tout résultat ne respectant pas la politique d'acceptation établie.

Enfin, 100 tests obsolètes ou en double ont été retirés du périmètre du projet pilote. Les 320 tests retenus ont été intégrés dans le flux d'intégration continue (CI) du client, validés à plusieurs reprises et vérifiés selon des critères de temps d'exécution, de stabilité, de taux de faux échecs et de maintenabilité.

Le périmètre défini pour l'évaluation comprenait l'authentification et les comptes utilisateurs, la recherche, le panier et le processus d'achat (checkout), le statut des commandes et les notifications aux clients. Les problèmes liés à l'environnement et les défauts du produit ne relevant pas de ce périmètre ont été enregistrés comme des dépendances.

Les ingénieurs en assurance qualité ont veillé à ce que les tests existants et ceux nouvellement créés respectent les exigences métier, les normes du framework et les règles de traçabilité, qu’ils soient validés par un contrôle humain et qu’ils conservent leur stabilité tout au long de la période de validation. Avant d’accepter un test, les défauts devaient être classés comme des incidents liés au test lui-même, aux données, à l’environnement ou au produit. Cette politique a permis que le résultat final de 320 tests reflète la maintenabilité réelle de la suite de tests et non pas simplement sa taille.

Dans le cadre des livrables du projet, le client a reçu le registre de classification, le code corrigé, la configuration CI, un guide opérationnel et un backlog technique. Le transfert a également permis d'identifier les dépendances d'environnement nécessitant une intervention de la part du client, ainsi que les futures initiatives d'automatisation à mettre en œuvre lors d'une phase distincte de mise à l'échelle.