TL;DR
Dans nos métiers, nous avons l’habitude de classer les tests en fonction du périmètre testé (tests unitaires, d’intégration, fonctionnels), potentiellement en fonction de comment on test (en boite noire, en boite blanche, par fuzzing, par mutation), et on a une petite place supplémentaire pour les tests de performance, les tests d’intrusions, voir deux trois petites choses à coté. Voilà. On a des tests, potentiellement pour différentes raisons (facilité de developpement, bonnes pratiques, habitudes), les devs les écrivent lorsqu’ils produisent les fonctionnalités ou lorsqu’ils corrigent des bugs. Et c’est très bien. Cet article a pour but de présenter une façon différente d’aborder les tests : les aborder par «qui garanti quoi vis à vis de qui ?». Une fois qu’on a répondu à cette question ça change grandement la façon de catégoriser les tests et la façon de le écrire.
Un exemple industriel
Mon approche sur les tests étant lourdement influencée par mon expérience chez EDF, on va commencer par résumer grossièrement comment fonctionne une centrale de production d’électricité.
On va globalement séparer les services en deux : le service conduite qui assure l’exploitation du réacteur (et donc la production énergie) et les services de maintenance qui assurent les opérations sur le matériel (en préventif ou correctif).
Comment va se passer une opération de maintenance ?
Prenons un exemple.
Pour une raison quelconque (anomalie constatée, opération périodique…), il faut faire le contrôle d’une pompe. Si on purge tous les éléments de procédure pour se concentrer sur ce qui nous intéresse :
- la conduite va poser des scellés sur les disjoncteurs et vannes pour isoler la pompe du reste de l’installation,
- les différents services vont faire ce qu’ils ont à faire (débrancher la pompe, retirer les capteurs, déposer la pompe, la visiter, reposer la pompe, remettre les capteurs, etc)
Et là, avant de remettre le matériel en exploitation, il va y avoir deux choses à faire : une requalification intrinsèque et une requalification fonctionnelle.
La requalification intrinsèque est faite par le service de maintenance, alors que le matériel est encore isolé. C’est une première étape de vérification de la performance du matériel permettant de dire «De ce qu’on peut évaluer en isolation, le matériel va fonctionner normalement». Un peu comme lorsqu’on a changé une chambre a air sur un vélo, il est encore à l’envers sur le guidon, on vérifie que le pneu est gonflé uniformément et on considère qu’on peut faire un test plus poussé.
Si tout est bon, on va opérer une requalification fonctionnelle. Là, l’exploitant à partir de ses connaissances sur le matériel et des contraintes auxquels il est soumis va décider de comment il test le matériel avant de le remettre en condition d’exploitation. Un peu comme après avoir remis le vélo à l’endroit, on sautille sur le vélo, on accélère un coup puis on freine ; histoire de vérifier que tout réagit normalement avant de repartir «pour de vrai».
L’élément que je tiens à souligner dans cette requalification fonctionnelle, c’est que c’est l’exploitant qui décide comment il teste le matériel avant de le remettre en exploitation. Ce qui est logique puisque c’est lui qui est responsable de l’exploitation. L’autre élément important qui est en filigrane est que l’exploitant a besoin d’avoir une excellente connaissance sur les équipements.
Et les essais périodiques ?
Les essais périodiques sont… des essais… fait régulièrement… pour s’assurer que l’exploitation fonctionne normalement. Par exemple, on va s’assurer qu’entre le moment où on appui sur l’interrupteur pour actionner un générateur de secours et le moment où il démarre il s’écoule moins d’un certain temps.
Pour résumer
Si on résume, on a :
Une requalification intrinsèque faite par la maintenance, dans un environnement isolé, pour garantir à l’exploitant qu’il n’y a rien d’évident qui serait bloquant (une vis manquante, un axe voilé, etc)
Une requalification fonctionnelle faite par l’exploitant, en environnement contrôlé, pour lui garantir qu’il peut remettre le matériel en exploitation et garantir à l’autorité de contrôle qu’il respecte les normes attendues.
Des essais périodique piloté par l’exploitant, en production, qui garantissent à l’autorité de contrôle que les équipements fonctionnent correctement.
Que retirer de tout ça ?
À partir de là, j’ai plusieurs impressions qui ressortent :
- On a l’habitude de faire de la qualification fonctionnelle. Les équipes de développement écrivent des tests unitaires et fonctionnels avant de livrer une feature. Ça fait partie du process, mais c’est un process interne aux équipes.
- Grâce à la conteneurisation, on en déduit qu’on est iso-prod et que ça va marcher pareil en prod.
- On est bien outillé pour surveiller ce qu’il se passe en production, surveiller la disponibilité, avoir des métriques
Alors quel est le souci ?
Le souci, c’est que la responsabilité «L’ensemble doit fonctionner en prod» est à la fois dilué un peu partout entre les équipes «système» et les équipe de «dev». Et du fait de cette dilution, le poids de cette responsabilité va être plus écrasant. Prenons l’exemple d’un test fonctionnel de création d’un compte. Est-ce que j’ai beaucoup moins confiance dans le test s’il utilise une BDD sqlite en mémoire plutôt qu’un vrai serveur MySQL comme en production ?
Et si on est un peu plus confiant avec le vrai serveur MySQL, est-ce que ce niveau de confiance vaut l’effort supplémentaire de suivi des versions sur les environnement de développement ?
Cette question est intéressante. Elle vient assez naturellement à toute équipe de Dev, surtout si l’équipe n’est pas homogène d’un point de vue technologie et système d’exploitation. Et surtout,elle n’est pas du tout liée au fait d’être serein sur les productions. Pour prendre un exemple un peu concret : dans mon souci d’avoir une exploitation fonctionnelle, je ne me pose même pas la question de si les équipes front compilent leurs framework depuis l’env «iso-prod» ou s’il le font depuis leur environnement host parce que pour des soucis de performance, c’est plus pratique pour eux. Et je peux me permettre de ne pas m’intéresser à ce sujet parce que j’ai des tests end-to-end qui tournent avec un système d’installation et d’exécution que j’estime suffisamment proche de la réalité pour être serein. Mais si ça n’avait pas été spécifiquement mon rôle de faire en sorte que ça marche en prod, ça aurait été beaucoup plus compliqué de justifier le temps passé à la mise en place de cet environnement.
In fine, avoir des gens qui ont formellement la responsabilité de faire en sorte que «ça marche» fait que de solutions créées spécifiquement pour s’assurer que «ça marche» émergent. Créez des rôles spécifiquement pour s’assurer de la pérennité de la production et des solutions adaptées à votre environnement émergeront.