Quinze pour cent. C’est la part du temps de sprint qu’une équipe de quatre développeurs a fini par consacrer systématiquement à l’écriture et à l’entretien de tests, après plusieurs mois d’ajustements successifs. Ce chiffre n’a rien d’universel, il n’a de sens que rapporté au contexte qui l’a produit ; ce qui compte davantage, c’est la méthode qui a permis d’y arriver plutôt qu’un débat sans fin en réunion de rétrospective.
Avant cette méthode, la question « teste-t-on trop ou pas assez » revenait à chaque rétrospective sans jamais trouver de réponse solide, faute de données pour l’appuyer. Certains développeurs sentaient qu’ils passaient trop de temps sur les tests, d’autres estimaient au contraire qu’on en écrivait trop peu, et chacun avait raison sur des tâches différentes sans qu’aucune vue d’ensemble n’existe.
Pourquoi une intuition partagée ne suffit pas
Le temps passé sur les tests se dilue naturellement dans le temps global d’une tâche, sans ligne dédiée dans les outils de suivi habituels. Un développeur qui passe une matinée entière à stabiliser un test instable ne le note généralement pas séparément du reste du développement de la fonctionnalité. Sans cette visibilité, impossible de savoir si le temps investi correspond à un niveau de risque raisonnable ou à un gaspillage.
Fixer un budget en amont, dès la planification de sprint
La méthode consiste à réserver, au moment de la planification, un pourcentage du temps disponible de l’équipe explicitement pour les tests, distinct du temps de développement fonctionnel. Ce budget se décompose en deux catégories suivies séparément :
| Catégorie | Contenu | Part typique du budget |
|---|---|---|
| Tests nouveaux | Cas de test écrits pour les fonctionnalités du sprint | Environ deux tiers |
| Entretien de tests existants | Correctifs de tests instables, mise à jour de fixtures | Environ un tiers |
Suivre le temps réellement passé
Chaque développeur note, dans l’outil de suivi de tâches déjà utilisé par l’équipe, le temps passé sur chacune de ces deux catégories via une étiquette dédiée, sans complexité d’outillage supplémentaire :
Tâche : Ajouter le filtre par région au tableau de bord
Sous-tâche : Développement 4h
Sous-tâche : Tests [budget-tests] 1h30
Ajuster le pourcentage à partir des incidents constatés, pas d’une impression
Le budget initial de dix pour cent, choisi arbitrairement au premier sprint suivant cette méthode, a été révisé à la hausse après deux sprints marqués par des régressions en production qui auraient été détectées par des tests absents. La règle adoptée est simple : chaque incident de production imputable à une absence de test déclenche une revue du budget lors de la rétrospective suivante, avec une proposition chiffrée d’ajustement plutôt qu’une discussion générale sur « il faudrait tester plus ».
- Un incident lié à un cas non testé : proposition d’augmenter le budget d’un ou deux points.
- Deux sprints consécutifs sans incident et un budget jugé confortable par l’équipe : proposition de le réduire légèrement pour libérer du temps de développement.
- Le budget ne descend jamais sous un plancher fixé collectivement, ici cinq pour cent, quelle que soit la pression de calendrier.
Ce que cette méthode ne résout pas
Un budget de temps ne garantit pas la qualité des tests écrits pendant ce temps : une équipe peut très bien consacrer quinze pour cent de son temps à des tests superficiels qui ne couvrent aucun cas limite réel. Le budget encadre l’effort, pas la pertinence de cet effort, ce qui reste du ressort de la revue de code habituelle.
Un budget de temps pour les tests n’est pas une cible à atteindre coûte que coûte : c’est un repère qui rend visible un arbitrage jusque-là invisible, pour le rediscuter avec des données plutôt qu’avec des impressions.
Distinguer un budget d’équipe et un budget par tâche
Certaines tâches, comme un correctif visuel mineur, ne justifient presque aucun temps de test dédié ; d’autres, comme une modification du calcul de facturation, en exigent bien davantage que la moyenne. Le budget se raisonne à l’échelle du sprint entier, jamais tâche par tâche de façon rigide, pour laisser cette flexibilité nécessaire.
En résumé
Allouer un budget de temps fixe aux tests, suivi séparément du développement fonctionnel et ajusté sprint après sprint selon les incidents réellement constatés, transforme un débat récurrent et sans fin en une décision documentée et révisable. Le chiffre exact importe moins que la discipline de le mesurer, de le questionner et de le faire évoluer avec les faits plutôt qu’avec les convictions du moment.
