Comment organiser ses tests et son patrimoine de test ?

Beaucoup de testeurs sont en panique quand on va livrer en production. Comment se rassurer le plus efficacement sur la qualité de ce qui va partir ? Comment tester le plus efficacement en évitant au maximum de tester plusieurs fois ?

De plus tout le monde n’a pas la chance d’avoir tous ses tests automatisés et pouvoir tout tester en dormant…. À bon entendeur…

On va commencer par planter le contexte. Déjà tout ce que je vais décrire peut très bien fonctionner que l’on travaille sur des cycles courts et répétés comme en agilité ou sur des cycles plus long tels les cycles en V. Et ensuite quel est notre objectif ? Livrer de la nouvelle matière en production en l’ayant testé tout en n’ayant pas dégradé l’existant.

Dans le scénario suivant on va partir du principe que l’on a rien d’automatisé. Cela va permettre de mettre plus en avant encore la nécessité d’une bonne organisation.

1- Dès qu’une feature est présentée par les métiers ou le Product Owner nous, testeurs, allons pouvoir commencer à travailler dessus. La première étape consiste à faire ce que l’on appelle un Test Statique. On va étudier la documentation écrite, analyser si on identifie pas des manques de précisions dans les fonctionnalités décrites. Peut être pourrons nous signaler à ce moment là que certains cas métiers ne sont pas prévus, impossibles ou n’ayant pas lieu d’être. En général le testeur connait très bien le produit, il peut faire ce genre de retours.

Une fois fait vient le moment de la rédaction de la matrice de test. Bon là c’est le classique, on va lister les différents cas de test, les cas passants, les cas non passants, les cas aux limites…… et on va tacher d’identifier les entrées et résultats attendus de chaque cas de test. Et enfin on va identifier les jeux de donnée nécessaires.

Voilà c’est bon on est prêt… mais où donc en est le développeur qui travaille sur cette feature?

2- C’est bon le développeur vient de terminer de développer la fonctionnalité. Il vient de la livrer sur mon environnement de test.

A ce moment là j’ai envie de me jeter dessus et de commencer à dérouler tous mes cas de test…. erreur grave !

Il faut mieux prendre 10 minutes et faire quelques vérifications avant. On va par exemple vérifier que c’est la bonne matière qui est déployée. On peut aussi, si le produit a un front, vérifier que les principaux écrans s’affichent correctement. Si on a une API, rapidement vérifier que ses ressources renvoient des 200. Peut importe ce qu’elles renvoient, on veut juste s’assurer que le déploiement est valide.

Si on s’aperçoit d’un souci lié au déploiement alors que l’on a déjà commencé à tester, il va falloir redéployer….. et cela remet en cause tous les tests déjà passés qu’il faudra probablement refaire. Souvent on appelle ces vérifications des Tests d’Admission.

3- Si c’est tout bon alors on peut attaquer les Tests sur notre feature. Bon je ne vais pas trop m’attarder là dessus car cela ne relève pas trop de l’organisation générale de ses tests. Et la plupart d’entre vous maitrisez le sujet.

On va réitérer ces étapes plusieurs fois avant de partir en production. Ceci à chaque fois qu’une nouvelle fonctionnalité sera développée.

4- C’est bon on va partir en prod, on a la date. Mais on n’y va pas de suite, c’est dans 3 semaines. Les développeurs vont nous constituer le paquet de prod et vont le déployer sur un environnement de pré production afin de le tester.

On est serein on a déjà testé toutes les nouvelles features une par une et on s’est baladé sur le reste de l’application pour faire de la non régression.

Et là c’est la faute !

Ce paquet, il n’a jamais existé. Donc on ne l’a jamais testé en vrai non ? En effet jusqu’à présent on a eu les features les unes après les autres C’est la première fois que l’on va avoir entre les mains une version du produit contenant l’ensemble des nouvelles fonctionnalités. Et on ne peut y échapper, on doit se rassurer sur la qualité de ce que l’on envoie.

Sauf que si on a travaillé un an sur le produit (cycle en V) on a pas un an pour tout retester. Dans une moindre mesure le souci reste le même en agile. Comment faire ?

On va parcourir chaque matrice de test de chacune de nos nouvelles fonctionnalités et on va en extraire les tests correspondants à la base de chaque parcours métier (cas nominaux). On oublie les cas non passants, les cas aux limites etc…. ce n’est plus le moment de les tester, on est censé l’avoir déjà fait.

Une fois tous ces tests identifiés et regroupés (on appelle ce regroupement les Sanity Tests) on va les exécuter pour déjà vérifier que la matière existe bien sur le paquet de prod et ensuite s’assurer que le besoin métier principal fonctionne sans souci.

On va aussi inclure dans les sanity test les tests de toutes les anomalies corrigées que ce paquet comporte dès sa première version. Vous savez, toutes ces petites anomalies mineures que l’on a détecté en prod par exemple et que ne nécessitaient pas un correctif immédiat…

5- Cette étape réalisée, on sait désormais que toute la nouvelle matière qui justifie notre mise en prod est bien présente est valide. Et bien c’est le moment de se rassurer sur tout ce qui existe déjà en production. On va attaque les fameux TNR (Tests de Non Régression). On va tester toutes les anciennes fonctionnalités parties lors des mises en production précédentes et on va s’assurer que tout fonctionne. Si c’est à la main cela peut parfois être trèèèèèès long.

C’est pour cela que l’on ne le fait que à la fin. On ne passe pas les TNR tout le temps pour un oui ou pour un non quand on a rien automatisé. (on verra plus loin que l’on a quand même une solution efficace avec les Smoke Tests).

Si tout est bon et que l’on ne détecte pas d’anomalie alors on valide tout et on peut partir en production.

Et c’est là que normalement vous me posez la question…. comment est ce que l’on constitue notre bibliothèque de TNR ?

En théorie on a un premier moment maintenant. La nouvelle matière est en production et tout va bien. On va donc prendre nos Sanity Tests et les intégrer dans nos TNR. C’est ainsi que peu à peu notre patrimoine de TNR grossit.

Là je viens de vous décrire tout ce qui se passe quand il n’y a pas de souci ou d’anomalie détectés pendant les tests. Je vais tacher désormais de vous décrire ce qui se passe en cas de pépin. Déjà retenez la chose la plus importante, les étapes décrites ci dessus restent parfaitement valables.

6- Catastrophe ! On est en train de passer nos Sanity Tests ou nos TNR et une anomalie survient. Panique à bord ! Déjà on ne continue pas forcément nos tests. Ce point doit être évalué avec vos collègues testeurs ou votre test manageur. Mais surtout pendant que le développeur corrige on va tacher de déterminer ce que l’on appelle la Matrice d’Impact. C’est à dire, l’ensemble des parcours et fonctionnalités qui peuvent potentiellement être impactés par le correctif et nécessiter d’être testés à nouveau pour s’assurer que le correctif n’apporte pas de régression.

Attention, si cette recherche est obligatoire, il est possible que la matrice d’impact soit vide.

Le correctif est livré. On teste en premier que l’anomalie est effectivement corrigée (Test de confirmation ou re-test) et ensuite, si besoin, on passe les tests de la matrice d’impact. Une fois fait on peut reprendre notre process de test.

7- Plus haut je vous ai vaguement parlé des Smoke Tests. Que sont ils ? C’est un regroupement d’un petit nombre de tests issus de notre bibliothèque de TNR. En plus de ne pas être très nombreux, ils doivent couvrir dans les grandes largeurs les principales fonctionnalités du produit testé. On peut presque les voir comme un Best Of des TNR.

Souvent on va être confronté au fait que l’on va livrer des correctifs plusieurs. Des correctifs si lourds qu’il faudrait presque re jouer tous les TNR. Ou bien on a juste besoin de se rassurer avant de commencer à passer les Sanity Tests au tout début des différentes étapes de tests. Ou encore en complément des tests de la matrice d’impact….. on va les jouer dans ces cas là et donc assez souvent. C’est pour cela qu’ils doivent être assez peu nombreux, couvrir un périmètre à la fois large et essentiel du produit et surtout être extrêmement bien décrits et maintenus.

D’une manière générale, les Smoke Tests permettent de donner une réponse au concept de Pareto. En effet d’un part ce concept affirme que 80% des problèmes de qualité sont dûs à seulement 20% des causes. Ces tests là sont censé grosso modo représenter 20% des tests et couvrir 80% du périmètre fonctionnel.

8- Imaginez maintenant que vous avez une anomalie qui remonte en production. Ce n’est pas si grave, cela arrive. Mais cela veut dire qu’il y a un trou dans la raquette au niveau des tests. Une fois le test correspondant rédigé et l’anomalie résolue en prod il faut quoiqu’il arrive ajouter ce test à notre patrimoine de TNR. Même si l’anomalie est sur un cas à la marge, un parcours métier non principal et qui n’aurait jamais été dans le groupe des Sanity Tests (lors de la release de la fonctionnalité ayant l’anomalie) et donc n’aurait logiquement pas été intégré aux TNR.

Cependant faire ceci permet réduire le maillage de notre couverture de tests. C’est aussi une bonne façon (parmi d’autres) de réduire les effets du paradoxe du pesticide. En effet, à force de tester toujours les mêmes parcours métiers, le fait que nos tests soient validés perd de sa valeur. Procéder ainsi nous force à avoir de nouveaux tests passant dans des endroits du code moins testés.

Tous les tests dont on vient de parler sont ce que l’on appelle des test fonctionnels. Ce sont des tests qui vérifient que le système fait ce qu’il est censé faire. Ceci basé sur des spécifications fonctionnelles.Mais il est existe un autre niveau de test: ce sont les tests non fonctionnels. Ces derniers vérifient le « comment fonctionne le système ?». On va parler de bench, test de charge, test d’accessibilité, de comptabilité etc…. mais ça c’est pour autre fois.

Auteur : Romain GRANIER