Un parc de tests automatisés ne s’effondre jamais le jour où son auteur part. Il continue de tourner, proprement, pendant quelques semaines. Puis un déploiement casse douze scénarios, personne ne sait par où les prendre, on les désactive le temps de voir. Deux mois plus tard, la moitié du parc est en pause. Six mois plus tard, plus personne ne regarde les résultats.
Ce n’est pas un problème d’outil, c’est un problème de transmission. Et il se mesure avant de se produire.
Le risque, en trois questions
Posez-les à votre équipe aujourd’hui, les réponses prennent dix minutes.
Combien de personnes savent modifier un scénario existant sans aide ?
Si la réponse est une, vous avez un point de rupture unique sur la vérification de vos applications critiques.
Si cette personne partait demain, combien de temps pour qu’une autre reprenne son périmètre ?
Comptez en semaines de montée en compétence, pas en jours de passation.
Que reste-t-il d’exploitable si vous changez d’outil ou de prestataire ?
C’est la question de la réversibilité, et c’est celle qui coûte le plus cher quand la réponse est rien.
Dans beaucoup d’organisations, la vérification automatisée des parcours qui portent le chiffre d’affaires repose sur une personne et demie. Le même DSI qui exige un plan de continuité sur ses bases de données n’en a aucun sur son parc de tests.
Ce qui rend un parc reprenable
Un format lisible sans être l’auteur. Un scénario qui se lit comme une suite d’actions métier se reprend par quelqu’un d’autre. Un scénario écrit en code, sans convention partagée ni documentation, se reprend par quelqu’un qui connaît déjà le framework, l’architecture de test et les choix de son auteur. Ce n’est pas la même population, ni le même délai.
Des conventions, pas des habitudes. Nommage, découpage, données, gestion des attentes. Quand ces choix ne sont écrits nulle part, ils partent avec la personne.
Des données de test documentées. C’est la première cause d’échec d’une reprise. Les scénarios sont compréhensibles, mais personne ne sait quel compte utiliser, lequel est bloqué, ni pourquoi celui-là ne doit jamais servir en préproduction.
Un environnement qui ne vit pas sur un poste. Si l’exécution dépend d’une configuration locale, elle disparaît avec l’ordinateur.
La réversibilité. Un parc dont les scénarios s’exportent vers un format standard comme Playwright reste exploitable en dehors de l’outil qui l’héberge. C’est un des postes du coût réel de la maintenance des tests automatisés. C’est aussi ce qui permet de faire cohabiter une équipe qui code et des profils métier sur le même parc, donc de ne plus dépendre d’une seule personne.
Le cas du prestataire
Le risque est le même avec un prestataire, avec une nuance : il est contractuel, donc il se traite au contrat.
Trois clauses à vérifier avant de signer, pas au moment de partir. À qui appartiennent les scénarios produits. Sous quel format ils sont restituables. Ce qui se passe si la personne affectée à votre compte change, ce qui arrivera de toute façon.
Une prestation de QA qui ne restitue rien de réutilisable est une location, pas un investissement. Ce n’est pas disqualifiant, mais il faut le savoir au moment de comparer les prix.
Les trente jours qui suivent un départ annoncé
- Faire produire l’inventaire par la personne qui part. Ce qui tourne, ce qui est désactivé et pourquoi, ce qui est fragile et pourquoi.
- Lister les données de test et leur mode de renouvellement.
- Faire exécuter une réparation à quatre mains sur un scénario réellement cassé, pas sur un exemple. C’est le seul exercice qui révèle ce qui n’est écrit nulle part.
- Récupérer une copie exportable du parc, même si vous ne comptez pas changer d’outil.
- Nommer un propriétaire, même à temps partiel. Un parc sans propriétaire est un parc qui s’éteint.
Ce que ça change pour les grands comptes
Sur un parc multi-applications, multi-pays, refondu par vagues, le turnover n’est pas un accident, c’est une constante. Les équipes changent, les prestataires changent, les périmètres se redistribuent. La question n’est donc pas d’éviter les départs mais de faire en sorte qu’un départ ne coûte rien.
C’est un critère de choix d’outil à part entière, au même titre que la couverture fonctionnelle. Et il ne se voit pas en démonstration : il se voit trois ans plus tard.
Pour aller plus loin : la maintenance des tests avec Mr Suricate.
Questions fréquentes
Qui maintient les tests automatisés quand la personne qui les a écrits quitte l’entreprise ?
Personne, si le parc n’est lisible que par son auteur. La parade n’est pas la documentation, qui vieillit, mais un format de scénario compréhensible par des profils non développeurs et un parc exportable vers un format standard.
Combien de temps faut-il pour reprendre un parc de tests dont on n’est pas l’auteur ?
Cela dépend entièrement du format et de la documentation des données de test. Le bon indicateur n’est pas la taille du parc mais le nombre de personnes qui savent déjà modifier un scénario sans aide.
Faut-il documenter les tests ?
Documenter les conventions et les données, oui. Documenter chaque scénario, non : cette documentation devient fausse au premier changement. Un scénario lisible en lui-même vaut mieux qu’un scénario documenté à côté.
