Stratégie de test : Les écueils et les enjeux

Élaborer une stratégie de test, ça veut dire quoi ? En quoi ça consiste ? Pour comprendre l’importance de la stratégie de test dans un projet informatique, commençons par mettre le doigt sur les écueils à éviter avant d’en poser clairement les enjeux.

La pyramide des tests : Cas d’école des écueils à éviter

1^er écueil : Confondre stratégie de test et niveau de test

Les différents étages de la pyramide ne font que citer des niveaux de test. Un petit rappel sur ce que sont ces niveaux de tests.

• Le test unitaire consiste à isoler un morceau de code pour le tester. Ce sont des tests mis en place par les développeurs. Ce sont eux qui déterminent quels morceaux de code peuvent être isolés et quels tests peuvent leur être appliqués.
• Les tests d’intégration sont aussi des tests mis en place par des développeurs. Cette fois il s’agit de contrôler les échanges entre des morceaux de code.

Sur ces deux premiers niveaux ce sont des couches basses de l’application qui sont testées par les équipes de développement. Ce sont en quelque sorte des tests de fabrication. Les deux niveaux supérieurs de la pyramide concernent des tests qui contrôlent les fonctionnalités de l’application. Ils sont donc exécutés lorsque celle-ci est opérationnelle. La différence entre « Test système » et « Test manuel » c’est que les premiers sont automatisés.

Même si l’on peut convenir de l’intérêt de distinguer ces différents niveaux de test, ils ne peuvent en aucun cas constituer une stratégie de test satisfaisante. En effet :

• 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 ?

2^ème écueil : Perdre de vue le rôle et les compétences du testeur

La pyramide du test est une illustration flagrante de la mise à l’écart du 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 n’ont pas les compétences pour les coder. Leur rôle se borne aux tâches les plus ingrates : Donner des indications aux développeurs. Écrire les spécifications des tests à automatiser. Écrire et exécuter les tests manuels.

La pression à l’automatisation exclut les testeurs au profit « d’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.

3^ème écueil : Se limiter à l’application à tester

Le premier commentaire sous la vidéo du post de Micro Focus est éloquent. Il met le doigt sur cet écueil qui consiste à ignorer l’écosystème dans lequel évolue l’application. Il est en effet extrêmement rare qu’une application fonctionne en solo. Prenons l’exemple d’une application de e-commerce. Le traitement d’une commande passe par divers logiciels qui gèrent les stocks, le colisage, la logistique, le transport. D’où l’importance des tests End-to-End afin de contrôler le fonctionnement de l’ensemble de la chaîne de distribution dans la vraie vie. Souvent ces processus métiers passent par plusieurs applications utilisées par des acteurs différents. Les cas d’utilisation sont multiples. Comme le rappelle l’auteur du commentaire, ces tests sont souvent négligés. A tort, car c’est justement là que surviennent les bugs aux conséquences les plus graves.

Les enjeux de la stratégie de test

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 stratégie de test est justement là pour répondre à cette question. 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, celle 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. La principale raison, outre l’absence de stratégie de test, est la difficulté à automatiser ce type de test. Hormis l’Atelier de Qualification Scapin, il n’existe guère sur le marché de solution pour l’automatisation des test fonctionnels.