Cas client · Logiciel

Des tests automatisés à chaque merge, et un processus de release adopté par toute l’équipe

47 tests automatisés qui s’exécutent en moins de trois minutes à chaque merge, une seule stratégie de test et de release pour toute l’équipe, et des développeurs qui livrent désormais des tests avec chaque fonctionnalité.

Client
Un éditeur de logiciels américain qui développe des outils d’IA pour le monde du travail
Lieu
États-Unis, entièrement à distance
Défi

Le point de départ

L’entreprise développe des outils basés sur l’IA pour l’environnement de travail numérique. À mesure que le produit grandissait, les releases devenaient plus lentes et plus risquées : une modification dans une partie du système pouvait en casser une autre, et personne ne pouvait affirmer avec certitude qu’une release était prête. L’entreprise nous a demandé de l’aide, et toute la mission s’est déroulée à distance.

  • Aucun framework d’automatisation des tests. La qualité reposait sur des tests manuels, qui ne suivaient pas le rythme des mises à jour fréquentes.
  • Aucun processus clair pour vérifier les corrections de bugs : des problèmes corrigés réapparaissaient sans cesse.
  • Des tests sans procédures ni documentation communes : la couverture était difficile à évaluer et l’intégration des nouveaux arrivants prenait du temps.
  • Aucun plan de tests de recette : on ne savait jamais vraiment quand une fonctionnalité était prête pour la release.
Approche

Ce que nous avons fait

Outils

  • GitHub Actions
  • Playwright
  • Bruno
  • Python
  • TypeScript
  • Un pipeline de test dans GitHub Actions pour le frontend comme pour le backend, pour que des tests automatisés s’exécutent à chaque modification.
  • Des tests d’API automatisés qui vérifient que le backend fait bien ce que décrit la documentation du produit.
  • Des tests de régression automatisés pour le frontend, pour que les nouvelles modifications ne cassent pas en silence ce qui fonctionne déjà.
  • Chaque processus de test documenté par écrit, avec nos observations et nos recommandations sur ce qu’il faut améliorer ensuite.
  • Des tests exploratoires en parallèle de l’automatisation, et des ressources de test réutilisables que l’équipe peut enrichir elle-même.
Résultats

Ce qui a changé

  • Une première suite de 47 tests automatisés qui s’exécute en moins de trois minutes.
  • Les mêmes tests tournent en développement, en préproduction et en production.
  • Les tests s’exécutent automatiquement à chaque merge.
  • Les développeurs ont appris à écrire du code testable et livrent désormais des tests avec chaque fonctionnalité et chaque correction de bug.
  • Toute l’équipe de développement suit une seule et même stratégie de test et de release.
  • L’équipe pratique les tests exploratoires, avec des heuristiques et des chartes, pour trouver ce qui échappe aux tests scriptés.
  • Des déploiements plus fiables et moins de problèmes qui atteignent les clients.
« House of Test a complètement transformé notre manière de développer en intégrant un framework d’automatisation des tests dans notre pipeline existant. Ils ont également mis en place un processus de test et de release solide, pragmatique, efficace et adapté à notre environnement, à notre produit et à notre équipe. En quelques jours seulement, Alex et Andy avaient saisi tout le contexte de notre produit. Ils ont fait preuve d’une vraie initiative, de créativité et de solides compétences techniques et relationnelles, se sont parfaitement intégrés à notre équipe et se sont lancés directement dans la phase de mise en œuvre de notre projet. »
Chief Product Officer, éditeur de logiciels américain

Vous êtes face à une situation similaire ?

Parlez-nous de votre équipe et de ce sur quoi vous travaillez. L’un de nos ingénieurs reviendra vers vous.