Miserere nobis patrimonium - Ayions pitié de notre patrimoine

Dans sa vie, un Testeur peut être amené à s’enorgueillir ou se lamenter sur les milliers de tests présents dans son patrimoine. Dans un premier temps, l'orgueil peut venir de leur présence qui vient rassurer le Testeur et par ricochet, les parties prenantes du projet qui vont mesurer le potentiel de confiance sur le processus de développement à l'aune de la quantité de tests présents au titre de "l'Assurance Qualité".

Évidemment, c'est un sentiment de courte durée pour celui qui se retrouve à devoir (hélas trop tard) exhumer un test dans son patrimoine de test. C'est le cas lorsque notre malheureux Testeur se trouve à ne pas avoir mis à jour ses tests au bon moment ou de façon maladroite et créer de la "dette technique" .

Naturellement, le cas s'empire lorsque le Testeur a eu la "fausse bonne idée" de dupliquer les tests pour X raisons : que ce soit pour décliner des scénarios ou pour une tentative de gestion de version des campagnes de test : avoir plus de test amplifie par effet de levier tous les défauts de notre organisation du patrimoine.

Mais pourquoi "plus" est-il une source de "moins" ?

Aggravation du patrimoine

Gérer de grandes quantité de tests est une des difficultés du test et quelques facteurs réduisent l'industrialisation de ces tests.

Paradoxe du pesticide

Commençons par faire allégeance au standard : l'ISTQB énonce un principe nommé "Paradoxe du pesticide" qui prédit l'inefficacité d'un test à force d'utilisation et par conséquence son obsolescence .

Sans prise de conscience de ce principe, le premier réflexe est de vouloir conserver tous les tests, "au cas où". Ce "conservationnisme" peut être généré par une culture de traçabilité avec un niveau bien supérieur à ce qui est requis par le projet.

Dans cet état d'esprit, si chaque version introduit un grand lot de nouveaux tests, notre Testeur va se retrouver dans un état qu'on pourrait apparenter à la Syllogomanie popularisé sous le terme "Syndrome de Diogène" sur les aspect "d'accumulation compulsive objets [...] sans les utiliser, indépendamment de leur utilité ou de leur valeur [...]".

Vitre brisée

Voici une métaphore souvent rencontrée dans le contexte du Software Craftsmanship (traduisez "Artisanat Logiciel") pour illustrer une théorie utilisée en criminologie : si une voiture ou une maison montre des vitres cassées, cela appellera à d'avantage de vandalisme .

Dans le contexte de notre patrimoine de test en piteux état, le Testeur percevra un tas d'immondices auquel il n'aura aucun remord à en ajouter de nouvelles.

La dette technique

Le terme de dette technique vient d'une métaphore proposée par Ward Cunningham en 1992 . Il correspond à une augmentation du coût de réalisation compte-tenu de la dégradation du code car avec le temps, le développeur est confronté aux situations suivantes  :

insouciance / imprudence	prudence
(1) du code de faible qualité est intentionnellement envoyé en production sans action corrective car il faut passer à la suite - on agit sous la pression	(2) on répond à l'urgence en envoyant le code en production puis on tente de le consolider en corrigeant les imperfections	délibérée
(3) du code de faible qualité est envoyé en production sans avoir connaissance de ses faiblesses	(4) tout est fait pour une livraison de bonne qualité	involontaire

Dans tous les cas, le produit et sa structure vont se dégrader pour les raisons suivantes :

1. c'est le cas le plus évident, sous la pression on ne prend pas la peine de faire attention à la qualité des livrables, les modifications architecturales ont été faites en dépit des bonnes pratiques, les conséquences de ces décisions hâtives vont être cumulés aux mauvaises décisions héritées du passé et augmenter l'effort nécessaire pour les prochains changements.
2. c'est une attitude un peu plus mature sur l'organisation des mises en production dans l'urgence car elles sont complétées par une action de réduction de la dette technique, néanmoins, les corrections apportées à posteriori vont augmenter le coût de réalisation comparativement à une bonne livraison du premier coup
3. ici, le Développeur est dans une situation d'ignorance voire d'insouciance technique et dans ce contexte on peut imaginer que la dette technique est en grand danger car il y a alors
   • soit une réelle impossibilité de diminution de la dette par incompétence
   • soit une implication insuffisante voire de la désinvolture
4. malgré tout le savoir-faire et une organisation d'un niveau élevé, de la dette technique sera introduite dans le système , notamment à cause du second principe de la thermodynamique qui implique une dégradation inévitable du système dont l'entropie (grandeur représentant le désordre) augmente.

Le parallèle entre ce qui se produit sur le code et sur nos tests est évident : des tests de mauvaise qualité vont avoir une efficacité réduite

• sur la découverte des anomalies
• sur la maintenabilité des tests existants

et une mauvaise ingénierie viendra s'accumuler aux problèmes précédents.

Métaphore du mineur

Photo Agrillo Mario 2007

S'il devait bien y avoir un inconvénient aux cycles de développement itératifs tels que l'agile, ce serait l'accumulation avec livraisons précédentes qui vient empirer la situation. Dans ce contexte, on peut imaginer que notre Développeur (ou Testeur) est comme un mineur qui trouve régulièrement des filons dans lesquels il avance. En revanche, s'il ne revient pas en arrière pour mettre un peu d'ordre dans les éléments produits jusqu'à présent en renforçant les galeries par des soutènements, le mineur va tôt ou tard se retrouvé bloqué dans un effondrement...

Métaphore du jus de fruit

Scott Ambler propose la situation d'une bouteille de jus de fruit qu'on fait tomber malencontreusement... - voici les différentes situations :

• Un adulte se prendrait par la main et ferait le nécessaire pour éponger tout le jus répandu sur le sol
• Une autre possibilité serait de laisser la flaque de jus en espérant que quelqu'un autre s'en chargera ou attendre qu'il sèche...dans ce cas, il y a un risque que les suivants ne voient pas la flaque et en marchant dedans, ils vont en mettre de partout dans la maison, des mouches (bugs) vont probablement être attirées par le sucre puis le chien viendra lécher les traces et tombera peut-être malade...

Types de dettes pour le test

Pour nos tests, on peut identifier au moins 3 sources de dettes :

• la dette structurelle - les tests sont au mauvais endroit, la façon de faire n'est pas très maintenable
• la dette fonctionnelle - le test donnera trop de faux-positifs voire des faux-négatifs
• la dette de données - le scénario est correct, mais la donnée va induire un résultat qui va demander plus de travail (donnée périmée, dans le mauvais format, ...)

Bilan

Philippe Kruchten explore la gestion de la "dette technique" et indique son évolution dans la vie du projet  :

1. Apparition : le problème émerge de façon quasiment invisible, en tout cas sans réelle prise de conscience - "Tant qu'on ne sait pas que son lit est dur, on dort bien !" - Dans cette situation, on prend conscience que si personne n'a conscience du problème, alors il n'y en n'a pas ! Une sorte de chat de Schrödinger appliqué à notre dette...
2. Prise de conscience : les symptômes liés aux problèmes deviennent clairement visibles et leurs inconvénients se font ressentir
3. Point de bascule : c'est le moment où la charge de la dette devient inacceptable pour des raisons d'insatisfaction fortes ou financières
4. Assainissement : la décision de réduction de dette technique est prise et l'investissement commence à payer

Bonnes pratiques simples pour ne pas créer de la dette

Aurélie Chandèze réunit une liste de point à respecter pour avoir des tests faciles à maintenir comme :

• Pendant la conception des tests
  • Utiliser des standards de nommage
  • Utiliser une structure modulaire et calquée sur les domaines fonctionnels
  • Créer des tests faiblement couplés aux interfaces graphiques (voir SOLID plus bas)
  • Séparer les étapes de test des données
• Pendant l'exécution des tests
  • Vérifier que l’environnement de tests est stable
  • Utiliser des processus de lancement et de clôture
  • S’arrêter vite en cas de gros dysfonctionnement
  • N’arrêter le test que si c’est nécessaire
  • Séparer les tests qui visent à élucider un défaut des autres

Techniques d'améliorations

Scott Ambler fournit une liste de 11 principes autour de la notion de dette technique pour ne pas en générer  :

1. faire un peu de conception en amont
2. avoir un personne qui incarne l'architecture
3. garder un œil sur l'entreprise
4. réusiner pour réduire la dette technique
5. assurer la régression
6. automatiser l'analyse qualitative
7. mesurer la dette
8. gérer la dette de façon explicite
9. placer la réduction de la dette dans la culture
10. réduire la dette avant de livrer à un tiers
11. accepter une partie de la dette

Réduire la dette contenue dans le patrimoine correspond à une mise en conformité des quelques règles applicables au projet. Voici quelques une de des règles / heuristiques pour adresser toute ou partie de ces principes.

Appliquer des principes de design inspirés du code

Pour les nouveaux tests ou comme point de convergence sur le patrimoine, voici quelques exemples applicables sur la structure de vos tests :

• Principe DRY : "Don't Repeat Yourself" - éviter de dupliquer les scénarios de test. Ce principe implique une structuration de ses tests par des conditions initiales ou réutilisation de scénarios existants (sans que ce soient des tests pour de ne pas induire des dépendances entre les tests) afin de reproduire des étapes d'un scénario
• Adapter les Principes SOLID  :
  • Responsabilité unique (Single responsibility principle) : le test d'aura la responsabilité d'un seul objectif, l'exigence qu'il devra vérifier ; même si le scénario devait présenter des incidents, on pourra alors rapporter les anomalies mais le test ne sera pas KO pour autant - ce principe facilite la description grossière des tests (ils sont alors définis par "intention"), ce qui facilite la maintenance des tests et pousse notre Testeur à essayer d'aller jusqu'au bout du test afin d'en vérifier son objectif
  • Ouvert/fermé (Open/closed principle) : un test peut être étendu en termes de données mais son scénario ne devrait pas être modifié sinon on perdrait en cohérence
  • Substitution de Liskov (Liskov substitution principle) : un scénario de test pourrait être remplacé par un sous-scénario sans que cela ne modifie la cohérence
  • Ségrégation des interfaces (Interface segregation principle)  : préférer plusieurs tests d'interfaces spécifiques plutôt qu'un seul test général de l'interface
  • Inversion des dépendances (Dependency inversion principle) : il faut dépendre des abstractions, des tests plut[ot que des implémentations afin de conserver du sens sur les tests même si dans le détail les choses ont évolué
• Utiliser des "patterns de test" : à l'instar des design patterns (patrons de conception) , il existe des patterns (ou motifs voire techniques) de tests qui répondent à des situations données , ces patterns vont réduire la complexité du test et adresser au mieux le besoin de vérification

Vous pourrez trouver bien des principes d'architectures sur le wiki principles-wiki.net qui sont à prendre comme une source d'inspiration pour améliorer la structure de vos tests et bénéficier du recul d'autres expériences.

Réduction de la dette liée aux fonctionnalités

L'organisation des tests peut être pensée en termes de traçabilité avec

• les éléments du logiciels (ex : les composants ou plus finement les classes ou les fonctions, ce qui peut être extrêmement utile sur les tests unitaires voire d'intégration) - par exemple en regroupant les tests suivant les gros composants de sorte aussi à clairement identifier les tests bout-en-bout et les tests locaux à un composant
• les éléments fonctionnels (ex : les US/Epics, les fonctionnalités, les exigences, les liens entre les exigences et les US, ...)

L'analyse d'impacts d'un changement permet d'identifier rapidement les tests à examiner pour une éventuelle mise à niveau et procéder de façon délibérée à la maintenance de la dette fonctionnelle.

Réduction de la dette liée aux données

Un des remèdes les plus efficaces est de commencer à gérer ces données, par exemple par un dictionnaire.

Ce dictionnaire permet de retrouver une donnée suivant différents critères tels que

• les tests qui l'utilisent
• la méthode de génération
• sa date de création / péremption
• son éventuel statut en termes
  • de réservation (pour éviter les accès concurrents)
  • d'état (notamment si la donnée est persistante et que le métier lui impose une progression irréversible)

Avec ce dictionnaire, une certaine hygiène est nécessaire, par exemple :

• vérifier l'état de la donnée avant utilisation pour s'assurer de son utilisabilitée et éviter de faux résultats
• inspecter l'état du dictionnaire de façon systématique ou par échantillon renforce ce socle
• remettre (si possible) à l'état initial une donnée lorsqu'on arrive à la fin de son test

Organisation pour réduire la dette

L'ISTQB propose un processus de test qui inclut une phase de "clôture des tests" :

<< [...] durant la phase de clôture des tests d’un processus de test, les données sont collectées des activités terminées pour consolider les expériences, les testwares, les faits et chiffres. La phase de clôture des tests consiste en la finalisation et l’archivage des testwares, l’évaluation des processus de tests, incluant la préparation des rapports d’évaluation des tests. >>

Cette phase de clôture est un bon moment pour adresser la réduction de la dette et pour aller un peu plus loin que ce qui est écrit dans le standard, voici quelques pratiques.

5S

C'est une méthode qui vient de chez Toyota et synthétise 5 mots japonais commençant par le son "S"  :

• Seiri (整理, ranger) : supprimer l'inutile ;
• Seiton (整頓, ordre) : situer les choses ;
• Seiso (清掃, nettoyage) : (faire) scintiller ;
• Seiketsu (清潔, propre) : standardiser les règles ;
• Shitsuke (躾, éducation) : suivre et progresser.

Concernant la gestion de la dette, la clôture des tests peut ainsi être perçue comme un 5S sur les éléments du patrimoine tels que

• les anomalies,
• les tests,
• les scripts de tests,
• le dictionnaire de données (si on en a un),
• etc.

Petit à petit

Une autre stratégie pour réduire cette dette, rien de tel que de commencer à faire le job...maintenant !

Dès que l'on commence à populer son patrimoine, réusiner celui-ci dès que l'on sait avoir introduit une dette est une bonne pratique.

Une autre approche, moins mature mais plus naturelle est d'attendre l'émergence du point de bascule sur la dette, ce qui arrive lorsque le patrimoine de test est suffisamment conséquent et qu'une grande quantité de dette a été accumulée. Dans ce cas, il est nécessaire de disposer d'un backlog pour traiter la réduction progressive de la dette.

Ainsi, lorsqu'une dette technique est identifiée et intentionnellement non traitée (à cause de la pression ou de la priorisation des activités), le premier réflexe est évidemment d'ajouter une entrée dans le backlog puis lorsque c'est le bon moment, on traite la dette grâce

• à une marge d'action prévue dans la planification du sprint (ou du Gantt pour les moins agiles d’entre nous)
• à une routine quotidienne (ou liée au cycle de développement) qui vient indiquer le créneau réservé à cette activité

Boyscout

Un proverbe boyscout dit qu'après son passage il y a deux choses qu'il laisse derrière lui :

• rien
• et "merci"

Ainsi chacun peut adopter la stratégie du boyscout qui laissera son camp un peu plus propre à son départ qu'à son arrivée : chaque fois qu'un artefact sera visité, toutes ou partie des anomalies constatées seront traitées pour réduire petit à petit la dette.

Chiffrage de la dette

Une façon redoutable de prendre connaissance de sa dette et de la contrôler est de la chiffrer. Une première approche peut consister à simplement compter les défauts dans le backlog vu précédemment ; le problème est que certaines actions correctives / préventives sont plus coûteuses que d'autres. Une pondération des tickets en fonction d'une pondération pour y ajouter une priorisation est une bonne approche mais sachez qu'il en existe potentiellement autant qu'il y aura de personnes impliquées sur le projet car il n'y a pas de mesure absolue et seul un consensus sur ce chiffrage permettra de converger rapidement.

Ce chiffrage peut aussi s'estimer en jour.homme, voire en euros : un simple historique avec des données liées au temps passé sur les activités permet d'obtenir une moyenne de temps de traitement (s'il le faut avec une fourchette basse/haute, mais c'est superflu lorsqu'on démarre) et si vous connaissez le salaire moyen des Testeurs de l'équipe, vous connaîtrez le budget de réduction de la dette ; le montant sera certainement effarent mais cela pourra être utile pour identifier le niveau de qualité acceptable pour votre patrimoine : le point de bascule autour duquel on devrait gérer la dette ou le budget accordé pour traiter cette dette.

Liens entre les éléments de dette et analyse de cause racine

Une approche, très analytique, consiste à regrouper les tâches du backlog qui sont voisines d'un point de vue

• voisinage géographique
• similitude
• cause à effet

Le Process Area "Analyse causale et résolution" du CMMi propose à cet effet de faire le lien entre les anomalies pour permettre de traiter toute une même classe d'anomalies par la résolution de l'anomalie représentative de sa classe, comme pour la notion d'incident et problème vu par ITIL .

Pour une résolution plus pérenne, on va aussi tenter d'enlever la cause de l'anomalie et créer des actions préventives plus que correctives et par récurrence, tenter éradiquer la cause de la cause de la cause jusqu'à la cause première : la cause racine. Classiquement, la cause racine sera trouvée par des outils tels que

• les "5 Pourquoi"
• l'arbre des causes
• l'arbre des défaillances

Cette démarche est généralement très instructive car elle permet d'en découvrir un peu plus sur certains recoins de son application, en revanche elle comporte des limites tels que :

• la cause d'une situation finit par reboucler sur une cause d'un niveau inférieur
• cette approche permet d'éliminer des événements qui se sont déjà produits sans pouvoir anticiper sur ce qui se passera

Approche DMAIC

Pour trouver de façon plus empirique les actions préventives, il existe une approche nommée DMAIC qui signifie  :

• Define - définir
• Measure - mesurer
• Analyze - analyser
• Improve - améliorer
• Control - vérifier

C'est une approche du progrès continu couramment utilisée dans l'approche Six Sigma . Elle est basée sur la mesure factuelle d'amélioration des actions préventives identifiées sur l'hypothèse d'une cause potentiellement racine. Si l'amélioration n'est pas constatée, on tentera une autre mesure sur d'autres hypothèses et on pourra reboucler entre "Improve" et "Measure" autant de fois que nécessaire.

Appliquée à la lettre, cette méthode ne permet d'avoir un retour que sur des périodes d'environ 6 mois, mais il est complètement possible de faire un MiniDMAIC en réduisant le champ d'analyse et d'amélioration au seul projet.

Automatiser les tâches

Pour faciliter la prise en main de la dette technique, l'automatisation des manipulations du patrimoine est un réel avantage. Elle permet d'avoir pour certaines dettes

• un rapide retour sur une action de type DMAIC et de modifier ses conventions d'usages plus rapidement
• d'éviter des tâches répétitives et lentes qui aboutirait à des disparités dans l'homogénéité du patrimoine, ce qui serait peut être pire que la façon de faire précédente par la présence d'exceptions aux conventions adoptées

On notera que l'adoption de conventions facilitera l'automatisation de la réorganisation des tests.

Etat d'esprit Kaïzen

Scott Ambler introduit sur la méthode "Disciplined Agile" un guide sur l'amélioration continue qui reprend les bases du Kaïzen . Kaïzen est une méthode de gestion du progrès continu issu du "5S" évoqué plus haut et qui est à l'origine de principes tels que

• ‰Faire bien du premier coup en éliminant "tous" les défauts
• Ne pas chercher la perfection avant d'agir
• Solidaire plutôt que solitaire
• Se poser sans cesse la question pourquoi

et bien d'autres tels que  :

• être proactif sur la résolution de la dette
• remettre en question les pratiques actuelles (cet état d'esprit permet de sortir d'une "fausse bonne idée" trouvée par exemple avec un DMAIC )
• rechercher à diminuer les coûts des solutions
• favoriser le travail collaboratif
• ne pas blâmer : les problèmes d'aujourd'hui viennent des solutions d'hier
• travailler sur les causes plutôt que les effets
• éviter les gaspillages / irrégularités / excès
• favoriser le juste-à-temps

Une conséquence du Kaïzen et du principe du paradoxe du pesticide vus plus haut font que le Testeur aura tout intérêt à avoir un stock de test qui soit le plus petit possible.

Petit stock / grande capacité

Il est évident qu'une faible quantité de tests facilité beaucoup de choses, mais comment disposer d'un patrimoine qui soit toujours efficace, en particulier sur les tests de régression ? Tout va se jouer sur votre capacité à faire muter vos tests...

Au niveau des tests unitaires, lorsqu'on parle de mutation des tests, on génèrera des tests supplémentaires avec des opérations de mutation du code telles que des substitutions d'opérateurs (ex : on remplacera tous les opérateurs + par -) puis au lancement de ces tests, certains seront éliminés par eux-mêmes car ils sont inutiles . Le travail qui est proposé ici est au contraire un remaniement combiné à une simplification du patrimoine, une sorte de darwinisme appliqué aux tests, par exemple avec des réductions sur la base

• du niveau de risque d'un test
• d'une diminution progressive des tests à force d'utilisation (application du principe du pesticide avec une réduction de l'arsenal chimique)
• de la métaphore de la sécurisation militaire : conservation d'une poignée de tests de régression significatifs qui seront laissés comme des mines dont le déclenchement servirait d'alerte

Vous avez le choix dans la dette

N'y cherchez pas de contrepet, mais juste une invitation à une attitude délibérée de votre approche sur ce qui vous est le plus cher dans votre approche du test.

Maintenant vous savez !