[Programmez!] La chasse aux champignons

Cet article a été écrit pour et publié initialement dans le magazine Programmez!

J’entends souvent que le test c’est compliqué, qu’il est difficile d’avoir une vision d’ensemble ou tout simplement de le présenter avec un exemple compréhensible par un enfant de 6 ans.

En fait, comprendre les principes des activités de base du test c’est très simple. On peut d’ailleurs remarquer que ces activités se rapprochent fortement d’une activité que nous avons quasiment presque tous pratiqué : La chasse aux champignons !

Penchons-nous sur la chasse chasse aux champignons.

Le but d’une chasse aux champignons est de trouver des champignons. Néanmoins ce n’est pas si facile et si l’on veut arriver à un bon résultat il faut se préparer à cette chasse, bien la mener et bien sûr s’en servir pour les prochaines chasses.

Pour bien illustrer l’ensemble des activités relatives à une chasse aux champignons, je vous propose de passer par un processus.

La première chose à faire est de comprendre le contexte. Dans quelle forêt ou quelle parcelle allons-nous rechercher nos champignons ? Combien serons-nous de chasseurs ? Combien de temps durera cette chasse ? Comment nous-y rendrons-nous ? En quelle saison somme-nous ? Quelle a été et sera la météo avant notre chasse ? Il va de soi qu’en fonction de la réponse à ces question la chasse sera organisée différemment !

Après la compréhension de ce contexte nous avons la préparation de la chasse. Comment se regrouper avant la chasse ? Qui ramène quoi ? Un repas doit-il être prévu ? Quels champignons sont-ils recherchés ? Où devons-nous chercher en priorité ? Quelle est la taille de la parcelle sur laquelle nous chasserons ?

Vient alors la chasse en elle-même. On met en place la stratégie définie lors de la préparation et on s’adapte aussi en fonction de son évolution en concentrant plus nos efforts là où on trouve des champignons et en diminuant les recherches dans les coins pauvres en champignons.

Vient alors le Bilan. Ce bilan intervient à la fin de la chasse, et pour être honnête, c’est ce qui intéresse tout le monde ! Combien de champignons avons-nous récolté ? Les champignons récoltés étaient-ils bien les champignons cherchés ? La stratégie de recherche était-elle la bonne ?

• 

Les étapes d’une campagne de test, c’est pareil !

Partons du postulat que les champignons sont en fait les bugs.

Pour avoir des activités de test performantes il va falloir comprendre le contexte de notre application. Ici la question n’est plus quelle forêt mais plutôt quelle application ? Quelles sont les faiblesses de cette dernière ? Quel est le public visé ? Y-a-t-il des normes à suivre ?

Lorsque le contexte est compris il faut alors préparer sa ou ses campagnes de test. Dans ce cadre on définit comment sera testé l’application. En fonction des risques identifiés, les tests sont conçus et/ou sélectionnés avant d’être priorisés. On définit également l’ensemble des environnements et données de test afin de permettre aux testeurs de travailler dans des conditions optimales.

Vient alors la campagne de test. Lors de cette campagne on exécute les tests définit par la stratégie mais en fonction des événements et des bugs trouvés il est possible de réorienter nos recherches de bugs et donc la stratégie. Il n’est pas rare de devoir sacrifier certains tests peu prioritaire suite à un problème de délai ou à un risque qui a été sous-estimé et qui doit être couvert.

Arrive enfin le bilan. Tout comme pour les champignons, c’est ce bilan qui intéresse le plus grand nombre de personnes, et plus particulièrement les personnes n’ayant pas participé à la chasse. Lors de ce bilan on donne généralement un Go/No Go définissant si le niveau de qualité minimum souhaité pour l’application est atteint. De même, fait une rétrospective afin de savoir ce qui pourrait être amélioré et si notre stratégie (plan de test) a été efficace.

• 

L’analogie chasse aux champignons et activités de test c’est aussi une meilleure compréhension des principes de base du test !

Il existe 7 principes fondateurs du test dont 6 sont couverts par cette analogie qui permet de mieux les comprendre.

Ces principes sont :

Les tests montrent la présence de défauts : si on trouve des champignons sur une parcelle de forêt c’est qu’il y avait des champignons. Si on n’en trouve pas cela ne veut pas dire qu’il n’y en avait pas. C’est la même chose pour les tests ! En effet, les scénarios de test ne peuvent découvrir de bug que sur le parcours applicatif qu’ils traversent. Ils ne donnent donc pas d’information sur les sections non parcourues.

Le paradoxe des pesticides : Si on passe toujours au même endroit en cherchant des champignons, au bout d’un moment il n’y en aura plus dans ces zones alors que des champignons auront pu pousser à d’autres endroit de la parcelle. Cela se voit d’ailleurs aisément sur les gros sentiers qui ne compte que très peu de champignons à leur abord. C’est la même chose pour les tests. Si l’on fait toujours les mêmes tests on ne trouvera au final plus aucun bug alors que ces derniers pourront proliférer sur des sections non couvertes par les tests.

Les tests exhaustifs sont impossibles : Il est impossible de couvrir chaque cm² d’une parcelle ! De même, il est impossible de tout tester (ce qui explique en partie le premier principe énoncé plus haut). Ce principe est très simple à appréhender dès lors où l’on travaille sur des applications dont le nombre d’étapes consécutives possible est infini (ex : application mail).

Les tests dépendent du contexte : en fonction de la forêt et de la saison, les champignons recherchés seront différents, les techniques de recherches également. Sur un projet de test, c’est pareil les stratégies et besoins en test sont différents en fonction du fonctionnel, des technologies utilisées et de tout autre élément du contexte (ex : niveau de qualité à atteindre).

Il faut tester tôt : Plus tôt on découvre un champignon, moins gros est le champignon. Si on considère que le poids (ou la taille) d’un champignon correspond au cout de correction du bug, on arrive à ce qui a permis l’émergence du « Shift left », plus tôt on détecte une anomalie, moins elle coûte cher à corriger.

Les défauts (bugs) sont regroupés : Lorsque l’on tombe sur un champignon, on peut être sûr d’en trouver des identiques à proximité. Pour les bugs, c’est pareil ! Lorsque l’on en trouve un, il y a de fortes chances que d’autres bugs similaires soient présent sur la fonctionnalité en question.

Et on peut même aller encore plus loin !

Il y a des champignons vénéneux : ces champignons peuvent être assimilés à des faux bugs, remontés par des tests pas assez bien conçus.

Il y a des champignons que nous ne souhaitons pas ramasser : ces champignons peuvent être assimilés à des bugs que l’on ne souhaite pas corriger et ce pour de multiples raisons comme le coût trop important, l’adoption du bug par les utilisateurs…

La chasse aux champignons nécessite des outils comme un panier, un bâton, des chaussures de randonnée : pour le test c’est pareil ! Le panier peut même être comparé à gestionnaire d’anomalie

L’expérience d’un chasseur de champignon détermine en partie sa faculté à trouver des défauts : tout comme l’expérience et la connaissance d’un produit permet à un testeur d’être plus efficace (et pas uniquement à l’exécution)

Le poids d’un champignon peut être assimilé au coût de la correction.

L’espèce du champignon peut quant à elle être assimilée à un type de bug. Par exemple, les Bolets peuvent être considérés comme des bugs fonctionnels et les poids de moutons comme des bugs liés à la performance.

Adapter ses recherches est essentiel, particulièrement lorsque l’on passe régulièrement sur une parcelle. On a ici l’intérêt des tests exploratoires qui sont de plus en plus préconisés dans les méthodes incrémentales et donc agiles.

La stratégie de recherche pour une parcelle ou une forêt peut être comparée au plan de test.

Chaque forêt peut être considérée comme une application. Chaque forêt est différente et à ses spécificités. En fonction de ces spécificités les champignons recherchés seront différents et le nombre de personnes nécessaires pour la parcourir également.

Chaque parcelle de forêt comme une grosse fonctionnalité de l’application. C’est le même principe que pour les forêts tout en sachant que le type de champignon trouvé sur différentes parcelles d’une même forêt est souvent proche.

Les arbres, les plantes et les pierres, présents dans la parcelle ont un impact direct sur le type de champignons qui poussent. Ces éléments peuvent être considérés comme l’environnement technique

La faune fait évoluer la parcelle (par exemple, les sangliers remuent la terre, les écureuils ramassent les glands…). Ces animaux peuvent être considérés comme des partenaires avec qui l’application communique mais n’étant pas sous le contrôle du logiciel.

La pluie peut quant à elle est comparée aux changements apportés à l’application et donc les mise en production/mise en service car la pluie permet de faire pousser les plantes et les champignons et donc de faire évoluer la forêt qui est l’analogie de l’application.

Les promeneurs peuvent quant à eux être considéré comme des utilisateurs. Promeneurs qui, comme les utilisateurs peuvent trouver des champignons et décidé ou non de la ramasser (le cas de ramassage peut être considéré comme la remonté du bug à l’équipe de support).

Pour résumer on peut avoir ce tableau de correspondance :

Chasse aux champignons	Activités de test
Champignon	Bug
Poids du champignon	Coût de la correction
Espèce de champignon	Type de bug (fonctionnel, performance…)
Champignon non comestible	« Faux » bug
Champignon détecté et non ramassé	Bug à ne pas corriger
Stratégie de recherche	Plan de test
La forêt	L’application
La parcelle	Une fonctionnalité de l’application
La flore (arbres, plantes)	L’environnement technique
La faune (animaux)	Les partenaires
La pluie	Les mises en production
Les promeneurs	Les utilisateurs
L’expérience du chasseur	L’expérience du testeur
Le bilan de la chasse	Le bilan des tests La rétrospective pour l’amélioration continue

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.