Tests

Ce thème mesure la confiance que l'on peut accorder à un changement avant de le livrer. Les promesses portent sur le résultat : combien de temps pour savoir qu'on n'a rien cassé, quelle…

Guide≈ 8 min de lectureVérifiéLecture

En bref

Ce thème mesure la confiance que l'on peut accorder à un changement avant de le livrer. Les promesses portent sur le résultat : combien de temps pour savoir qu'on n'a rien cassé, quelle part des défauts est attrapée avant la production, et à quel point les tests eux-mêmes sont fiables (pas de test « clignotant »).

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Tableau des cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : TST (matrice DL)

Pourquoi ce thème#

Sans tests automatisés fiables, chaque livraison est un pari : on compense par des recettes manuelles longues, des gels de code et de la peur. La fréquence de livraison s'effondre, les lots grossissent, donc le risque par livraison augmente — un cercle vicieux. Avec de bons tests, un changement est validé en minutes, et la peur de modifier disparaît.

Mais les tests mal conçus coûtent cher : un test instable (flaky) apprend à l'équipe à ignorer la CI rouge ; un test couplé à l'implémentation casse à chaque refactoring ; une couverture élevée avec des assertions vides rassure à tort. Ce thème mesure donc la capacité de détection et la fiabilité de la suite, pas le volume.

Cas datamart : tester du SQL est possible et rentable (tests de procédures avec un jeu de données de référence, comparaison de résultats attendus, tests d'idempotence : rejouer deux fois donne le même état). La recette sur chiffres métier relève du thème recette et validation métier de la matrice data ; ici on parle de tests automatisés.

Ce que mesure le thème#

Axe : de « on teste à la main avant la livraison » à « la suite de tests est un détecteur calibré, rapide et fiable ».
Indicateurs clés : durée du retour de la suite rapide (minutes) ; taux de tests instables (%) ; score de mutation (part des mutants tués) ; taux de défauts de production détectables par un test existant.
Unité : minutes ; % ; défauts échappés par release.

Tableau des cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Manuel	Vous savez qu'une fonctionnalité marche parce que quelqu'un l'a essayée.	Aucune suite automatisée ; recette de plusieurs jours
2	Ponctuel	Les cas critiques sont rejouables à l'identique en quelques heures.	Tests automatisés sur les chemins critiques ; suite en heures
3	Systématique	Un changement est validé en moins de 15 minutes, sans intervention humaine.	Suite rapide < 10-15 min ; < 2 % de tests instables
4	Calibré	La suite détecte réellement les régressions : ce qui casse est vu, ce qui ne casse pas ne la fait pas échouer.	Mutation mesurée (≥ 60-70 % sur le cœur) ; pyramide respectée
5	Prédictif	Les défauts de production deviennent rares et chacun produit un test qui l'aurait attrapé ; la suite guide les décisions de livraison.	> 90 % des défauts échappés ont un test de non-régression ; tests en production maîtrisés

Jalons par niveau#

ID	Jalon	Preuve vérifiable
DL-TST-1.1	Une procédure de test manuelle existe pour les parcours critiques	Document ou liste de cas rejouable
DL-TST-1.2	Les anomalies trouvées sont consignées et rattachées à une version	Traçabilité anomalie → version
DL-TST-1.3	Un environnement de test distinct de la production existe	Environnement identifié et accessible
DL-TST-2.1	Les chemins critiques disposent de tests automatisés rejouables	Exécution sur poste neuf réussie
DL-TST-2.2	Les tests ont des données de référence maîtrisées (jeu versionné, base reconstructible)	Reconstruction à l'identique prouvée
DL-TST-2.3	Chaque défaut corrigé reçoit un test de non-régression	Revue de 10 correctifs récents
DL-TST-2.4	Les résultats de test sont archivés par version	Historique consultable
DL-TST-3.1	La suite rapide (unitaires + intégration légère) s'exécute à chaque changement en < 15 minutes	Durée mesurée en CI
DL-TST-3.2	Une pyramide explicite : majorité de tests rapides, peu de tests de bout en bout	Répartition chiffrée par couche
DL-TST-3.3	Le taux de tests instables est < 2 % et chaque test instable est mis en quarantaine sous 48 h	Suivi des nouvelles instabilités
DL-TST-3.4	Les tests ne dépendent ni de l'heure, ni de l'ordre d'exécution, ni de données partagées	Exécution en ordre aléatoire et en parallèle réussie
DL-TST-3.5	Les tests d'idempotence des traitements de données (double exécution) existent	Test rejouant deux fois le même lot
DL-TST-4.1	La couverture est mesurée par branche sur le cœur et suivie dans le temps	Rapport de couverture par module
DL-TST-4.2	Un test de mutation est exécuté régulièrement sur le cœur ; son score est suivi	Score ≥ cible fixée par l'équipe
DL-TST-4.3	Les tests de contrat protègent les interfaces consommées/produites	Tests de contrat en CI côté producteur et consommateur
DL-TST-4.4	Les tests de propriétés ou de données générées couvrent les règles de calcul critiques	Existence sur ≥ 3 règles métier
DL-TST-4.5	Les tests de performance de non-régression bornent les opérations critiques	Seuils versionnés
DL-TST-5.1	Tout défaut échappé est analysé : pourquoi aucun test ne l'a vu ? un test est ajouté	≥ 90 % des défauts échappés ont un test associé
DL-TST-5.2	La suite est sélective : seuls les tests impactés tournent à chaque changement, la suite complète en continu	Durée de retour < 5 min médiane
DL-TST-5.3	Des tests en production maîtrisés (déploiement progressif, bascules, surveillance synthétique) complètent la préproduction	Parcours synthétiques actifs
DL-TST-5.4	L'évolution du coût de maintenance des tests est mesurée et pilotée	Part du temps passé à réparer les tests < 10 %

Lecture détaillée par niveau#

🟢 Niveau 1 — Manuel#

Signes : la recette dure plusieurs jours ; « on testera en préprod » ; les régressions réapparaissent.
Gain : zéro investissement initial.
Ne garantit pas : la reproductibilité, la couverture, la rapidité.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Ponctuel#

Signes : quelques tests automatisés sur les chemins qui ont déjà cassé ; un jeu de données de référence existe.
Gain : la peur diminue sur les zones couvertes.
Ne garantit pas : que la suite soit rapide ni fiable.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Systématique#

Signes : un changement ne part pas sans retour de la suite ; les tests lents sont séparés des rapides ; les instables sont traqués comme des défauts. La pyramide (beaucoup de tests unitaires, moins d'intégration, peu de bout en bout) est un choix d'économie : le coût d'un test croît avec sa portée.
Gain : boucle de retour courte, livraisons plus fréquentes (05).
Ne garantit pas : que les tests détectent vraiment — on peut avoir 90 % de couverture et 0 assertion utile.
Difficulté : 3/5 · Effort : 3/5.

🔴 Niveau 4 — Calibré#

Signes : on mesure la qualité de détection : le test de mutation introduit de petites altérations du code (inversion de condition, borne décalée) et vérifie qu'un test échoue ; un mutant survivant révèle une assertion manquante. Les contrats entre composants sont testés des deux côtés.
Gain : une suite réellement protectrice, un refactoring sans crainte.
Ne garantit pas : l'absence de défaut de spécification (on teste ce qu'on a compris, pas ce qu'il fallait).
Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Prédictif#

Signes : chaque défaut échappé alimente la suite ; la sélection des tests par impact garde le retour sous quelques minutes ; la production est elle-même observée comme un test (parcours synthétiques, déploiement progressif).
Gain : la confiance découle de la preuve, pas de l'habitude.
Ne garantit pas : l'exhaustivité — on ne prouve jamais l'absence de défaut.
Difficulté : 5/5 · Effort : 5/5.

Atteinte partielle et notation#

Appliquez la règle de notation.

0,5 sur DL-TST-3.3 : le taux de tests instables est mesuré (5 %) mais la quarantaine n'est pas systématique.
0,5 sur DL-TST-4.2 : mutation lancée une fois, ponctuellement, sans suivi.
Un 5 partiel : chaque défaut échappé donne un test, mais la sélection par impact n'existe pas : la suite tourne en 25 minutes.

⚠️ Piège

Couverture rassurante. Symptôme : 85 % de couverture de lignes, et pourtant un correctif casse un calcul. Cause : la couverture mesure ce qui est exécuté, pas ce qui est vérifié. Remède : couverture par branche + mutation sur le cœur ; ne jamais fixer la couverture comme objectif individuel.

⚠️ Piège

Tests clignotants. Symptôme : « relance, ça passera ». Cause : horloge, ordre, données partagées, attentes fixes. Remède : isoler, rendre déterministe, mettre en quarantaine sous 48 h, comptabiliser.

💡 Astuce d'expert

Mesurez le temps moyen de retour et le taux de reruns de la CI : c'est l'indicateur indirect le plus fidèle de la santé de la suite.

Passer au niveau suivant#

Moyens possibles (facultatifs)

1 → 2 : démarrer par les défauts déjà vus ; automatiser d'abord les parcours qui coûtent le plus cher à rejouer à la main.
2 → 3 : séparer rapide/lent, jeu de données reconstructible (base reconstruite depuis les scripts), exécution parallèle et aléatoire pour débusquer les dépendances d'ordre.
3 → 4 : outils de mutation sur un module à la fois ; tests de contrat ; tests de propriétés pour les calculs financiers/arrondis.
4 → 5 : analyse systématique de chaque échappée ; sélection par impact ; surveillance synthétique de production.

🧪 Exemple

Consolidation d'un datamart : le test d'idempotence rejoue le même lot deux fois et compare l'empreinte (comptes + somme de contrôle par table de faits). Il trouve en 20 secondes un doublon que la recette manuelle ne voyait qu'au bout d'un mois. Sans ce test, le défaut survivait car chaque exécution isolée semblait correcte.

🤖 IA

Génération de cas de test et de données : gain 4/5, risque 3/5 (tests qui valident le comportement actuel, y compris faux). Garde-fou : relire les assertions, valider par mutation que les tests générés détectent quelque chose.

⚠️ Piège (Goodhart)

Récompenser le nombre de tests produit des tests redondants ; récompenser la couverture produit des tests sans assertion. Récompensez la baisse des défauts échappés.

Voir aussi#

Voisins : 02 Qualité du code · 05 CI · 06 Déploiement · 09 Dette technique.
Autres matrices : BI — tests et fiabilité des chiffres · Data — qualité des données · Projet — qualité et recette.
Pratique : CI/CD · CI/CD pour la data · pièges et bonnes pratiques.
Glossaire · Notation.

✻ Rédigé par Claude Sonnet 5.5