Des KPIs d'automatisation qu'on peut vraiment présenter en sprint review

« On a 1 200 tests automatisés. » La phrase impressionne en réunion, mais elle ne répond à aucune question utile. Est-ce que ces tests protègent ce qui compte ? Est-ce qu’ils sont fiables ? Est-ce qu’ils font gagner du temps ?

Depuis que je fixe des objectifs trimestriels d’automatisation et que je présente leur suivi en sprint review, j’ai appris à choisir des indicateurs qui parlent autant au produit qu’à la technique.

Les indicateurs que je suis

1. La couverture des parcours critiques

Pas la couverture de code : la part des parcours métier critiques couverts par au moins un test automatisé. Si votre produit a 20 parcours critiques et que 14 sont automatisés, vous êtes à 70 %. Tout le monde comprend ce chiffre, du PO au CTO.

2. Le taux de stabilité

La part des exécutions qui échouent sans régression réelle (échecs dits « flaky »). C’est l’indicateur de confiance : au-delà de quelques pour cent, l’équipe arrête de regarder les résultats. Je le suis par test, pour savoir lesquels réparer en priorité.

3. La durée d’exécution

Le temps entre le lancement de la suite et le résultat. Une suite qui prend une heure ne sera pas lancée à chaque pull request. La parallélisation et le tri des tests par priorité sont souvent les leviers les plus rentables.

4. Les bugs trouvés avant la production

Combien d’anomalies les tests automatisés ont-ils détectées avant la mise en production, sur le sprint ? C’est l’indicateur qui montre la valeur réelle de l’automatisation, et celui qui justifie le temps investi.

5. L’avancement par rapport à l’objectif du trimestre

Un objectif clair (« automatiser les 10 parcours de paiement d’ici fin du trimestre ») et une courbe d’avancement sprint après sprint. Simple, visuel, motivant.

Les indicateurs que j’évite

• Le nombre brut de tests : il pousse à écrire beaucoup de petits tests peu utiles.
• Le taux de réussite global seul : 98 % de réussite peut cacher qu’un seul test, celui du paiement, échoue à chaque fois.
• La couverture de code comme objectif : utile pour les devs, trompeuse comme cible pour une stratégie de test de bout en bout.

Comment les présenter

En sprint review, trois minutes suffisent :

1. Un tableau de bord avec les cinq indicateurs et leur évolution sur les derniers sprints (Allure, un tableur ou l’outil de reporting de votre CI font très bien l’affaire).
2. Un fait marquant : un bug évité, un test réparé, un parcours ajouté.
3. Le prochain objectif pour le sprint suivant.

L’automatisation devient alors un sujet produit, et plus seulement une tâche technique de l’équipe QA.

Et demain ?

Avec l’arrivée des agents IA de test, ces indicateurs restent valables, mais il faudra en ajouter : part des tests générés par l’IA et validés par un humain, taux de faux positifs des agents, temps gagné sur l’écriture. J’y reviendrai quand les premiers agents de ce site sortiront du labo.