Elaborer une stratégie de test, ça veut dire quoi ? En quoi ça consiste ? Et qu’en est-il dans le contexte des développements Agile ? A ce propos commençons par dénoncer celle que préconisent les théoriciens de la méthode Agile : La pyramide des tests.
L’imposture de la pyramide des tests
Récemment sur LinkedIn, Micro Focus publiait une présentation vidéo de la « pyramide des tests ». Une méthode de test logiciel censée « garantir une meilleure qualité et un meilleur coût ». Elle consiste à faire :
Enormément de tests unitaires parce qu’ils sont faciles à automatiser par les développeurs eux-mêmes
Un peu moins de tests d’intégration parce qu’ils sont plus complexes à réaliser
N’automatiser que quelques tests système parce que c’est ce qu’il y a de plus difficile à développer et à maintenir
Faire un ou deux tests manuels pour se donner bonne conscience
Et hop le tour est joué !
La technique des filets dérivants !
L’idée sous-jacente de cette stratégie est que si l’on teste chacune des multiples briques de code, on éradique presque tous les dysfonctionnements potentiels. Cela fait peut-être beaucoup de tests mais ils sont faciles à automatiser. Ensuite il suffit de tester les communications entre ces différentes briques. C’est plus compliqué à réaliser, mais comme on a déjà éradiqué l’essentiel, on en fera moins. Quant aux couches supérieures du logiciel, le risque de dysfonctionnement peut être jugé faible, donc on fait peu de tests. Quelques-uns automatisés pour la non-régression et le reste exécuté manuellement
Sauf que ça ne marche pas. La chasse au bug ne se fait pas au filet dérivant. En témoigne la conférence d’un ingénieur de chez Doctolib lors du salon DEVOXX 2022. Je vous invite à la visionner à l’adresse suivante : https://www.youtube.com/watch?v=QL0HBeIAny0
Cette conférence dure 47 minutes. En résumé elle dit ceci. Dès lors que le code change, il faut refaire des tests unitaires. Et plus ça change plus il faut en refaire. En agilité, qui est une méthode de développement itérative, les restructurations de code sont constantes. Cela signifie que les tests unitaires sont constamment à refaire. Bref c’est impossible à maintenir ou alors très couteux.
Conclusion, la base de la pyramide est pourrie. Et quand bien même ce ne serait pas le cas cette stratégie ne peut en aucun cas être satisfaisante :
Les tests qui ont été automatisés sont-ils pertinents, utiles ?
N’y a-t-il pas des tests oubliés ?
N’y a-t-il pas des tests redondants ?
Les cas d’usage les plus critiques sont-ils correctement testés ?
Autrement dit, une telle stratégie de test pilotée par la difficulté réelle ou supposée d’automatiser les tests n’est rien d’autre qu’une imposture.
L’Agilité sans le testeur ?
L’offre d’automatisation dans son ensemble, sous influence des gurus de l’Agilité, a totalement mis à l’écart le testeur. Les tests unitaires et d’intégration relèvent exclusivement de la compétence des développeurs. Les testeurs souvent issus du métier ne savent pas coder. Leur rôle se borne aux tâches les plus ingrates : Donner des indications aux développeurs. Ecrire et exécuter les tests manuels.
La pression à l’automatisation les exclut au profit des automaticiens censés avoir la double compétence codeur-testeur. Outre que ces deux activités se marient mal, ce sont des profils difficiles à trouver. L’expérience montre que les automaticiens sont surtout codeur et assez peu testeur. De même que coder une application médicale ne vous fait pas médecin, coder des tests ne vous fait pas testeur.
Une stratégie de test pilotée par le métier
Ne nous voilons pas la face, tester est une charge. Un investissement, entendons dire parfois, mais dont le ROI repose sur un pire qui n’est jamais certain. Comment, dans ces conditions, définir et calibrer les moyens à mettre en œuvre ?
La question n’est pas nouvelle. Elle se posait à l’époque du cycle en V. Elle reste d’actualité avec l’Agilité. La stratégie de test est justement là pour y apporter une réponse. Sa finalité est d’optimiser l’effort de test. Tester ni trop, ni trop peu et uniquement ce qu’il est nécessaire de tester.
Identifier les risques et les enjeux liés à l’application à tester
La stratégie de test s’élabore sur la base d’une réflexion sur les enjeux propres au système à tester. Selon le secteur d’activité et le type d’application ce seront des enjeux réglementaires, financiers, sanitaires, techniques, marketing, commerciaux, sécuritaires, etc., la liste n’est pas exhaustive.
Ils s’identifient à l’aune des risques et les conséquences de leur non prise en compte. Cette réflexion dépasse le cadre de l’équipe projet. Divers services de l’entreprise sont susceptibles d’être impliqués, voire la direction générale dans certains cas. La stratégie de test est l’aboutissement de cette réflexion. Elle est menée et animée par la cellule Test/QA.
Définir des objectifs de test
La définition des objectifs de test est la formalisation de ce travail collectif sur les risques et les enjeux. Elle permet d’inventorier les exigences métiers et techniques, les règles de gestion à respecter, les contraintes d’usage, celles liées à l’expérience utilisateur, etc. Elle répond en définitive à ces questions : Que faut-il tester ? Quels tests sont les plus importants ?
Automatiser les tests fonctionnels
Les objectifs de test étant définis, l’étape suivante consiste à déterminer comment les vérifier. Quelques-uns de ces objectifs relèveront de tests de performance ou de charge. L’immense majorité concernera des cas d’usage qui relèvent du test fonctionnel et de bout en bout. Ce sont justement ces tests qui sont négligés par l’Agilité. Réputés difficiles à automatiser, les acteurs du marché du test esquivent. Certains se sont engouffrés dans des solutions d’intégration continue complexes, très techniques, éloignées des préoccupations du métier. D’autres obligent les testeurs à adopter des pseudo-langage ou à dessiner des organigrammes pour « pré-coder » les tests.
Aucune de ces solutions ne permet au testeur d’organiser son travail sur la base d’objectifs de tests bien identifiés.
La solution Scapin
Contrairement à ces solutions, la Plateforme de Qualification Scapin respecte le rôle et les compétences du testeur. Elle lui offre un environnement de travail compatible avec les exigences de la méthode Agile. Accessible aux experts métier comme aux équipes de développement, elle fluidifie la collaboration entre les acteurs du projet. Elle donne au testeur une totale maitrise de l’automatisation des tests. Avec Scapin, l’automatisation n’est plus une difficulté. Tout est simple, facile, rapide, à la main du testeur lui-même. Il organise son travail sur la base des objectifs de tests. Il gère les évolutions de l’application à tester. Il crée ses données de test. Il mène des campagnes de test sur des versions différentes de l’application. Scapin est un outil complet, puissant et riche qui couvre l’ensemble des activités du test
Commentaires