Testabilité au plus tôt

Pourquoi vous devriez faire le test le plus tôt possible

« Le test est un processus infini de comparaison de l'invisible à l'ambigu
afin d'éviter que l'impensable n'arrive à l'anonyme " - [Bach 06-2006].

Il est bien connu que le test exhaustif n'est pas possible [Guru99 2014] [Radid 2018-2], principalement en raison d'un temps limité dédié au test, sans parler de la créativité du Testeur pour imaginer des situations imprévisibles. Même s'il existe des situations très simples où le test complet semble possible car les cas sont finis. Il existe virtuellement cinq types de situations lorsqu'on pense à la testabilité [Rodríguez 2013] :

• (a) fini - le système est limité à un nombre fini de possibilités, par exemple face à une machine à état fini telle qu'un distributeur automatique de billets.
• (b) infinie, mais tout degré arbitrairement élevé de complétude partielle peut être atteint de manière finie - par exemple avec des tests de partition [XXXX].
• (c) infini dénombrable - par exemple lorsque tous les paramètres d'entrée sont basés sur des nombres entiers.
• (d) infini indénombrable - par exemple lorsqu'un paramètre d'entrée est basé sur des valeurs flottantes.
• (e) aucune suite de tests existante qui permettrait de savoir si un système est même testable

Dans toutes ces situations, la testabilité repose en fait sur quatre aspects :

• Ce qui est visiblement testable du point de vue de l'utilisateur - la "testabilité extrinsèque".
• Ce qui est testable mais non visible - la "testabilité intrinsèque".
• Quels sont les moyens techniques offerts pour tester le système sous test (SUT) - la "testabilité technique".
• Comment les connaissances sont-elles mises à la disposition de tout moyen de test - la "testabilité sociale" - doit-il s'agir d'un partage lors d'une pause café ou d'un processus bien connu ?

Si l'un de ces composants manque, les testeurs seront confrontés à la situation (e).

‍

De plus, il y a certaines situations qui empêchent la testabilité, l'une d'entre elles est appelée "dépendance implicite" : disons qu'un composant donné récupère la date directement du système d'exploitation, non seulement cela réduira la réutilisabilité du composant [Horré 2011] mais cela vous empêchera également d'exécuter un cas de test qui est censé se produire à une date différente si ce composant est impliqué. Par conséquent, la testabilité est quelque chose qui devrait être inclus au moins au moment de la conception [SAFe 2021-27] avec des dépendances explicites [DevIQ 2014] ou avec le "principe d'injection de dépendances" qui est l'un des principes SOLID [Martin 2002] [Moustier 2019-1]. En fait, pour permettre la qualité intégrée, la testabilité fait partie des "Architecturally Significant Requirements" (ASR) [Wikipedia 2021] et doit être fournie le plus tôt possible pour faciliter à la fois la conception et la testabilité.

Comme nous l'avons vu précédemment, la testabilité et les interactions sociales sont intimement liées : si personne ne connaît de moyen de tester quelque chose, les testeurs seront confrontés à cette situation (e). De plus, il semble également que la testabilité donne confiance car vous pouvez facilement connaître la fiabilité d'une partie testable du produit, à condition d'avoir suffisamment de temps pour cela ou d'avoir investi au préalable dans des scripts de test automatisés.

En ce qui concerne la testabilité et l'automatisation, le Lean Management comprend un élément appelé "Jidoka" (自働化) [Monden 2011], qui pourrait être traduit par "Autonomation", un mot-valise pour "Automatisation" et "Automation", et repose sur quatre principes :

1. Détecter l'anomalie.
2. Stop.
3. Réparer ou corriger la situation immédiate.
4. Recherchez la cause profonde et installez une contre-mesure.

L'idée derrière cela est de pousser un robot à devenir plus robuste aux pannes et de permettre à l'opérateur qui surveille les robots de passer moins de temps sur le robot maintenance. Jidoka devient extrêmement pertinent lorsqu'il s'agit de faux positifs sur des scripts de test automatisés. Si le script est capable de gérer les situations qui peuvent conduire à générer des faux positifs, le pipeline d'intégration deviendra plus robuste et livrera le produit plus souvent, pratiquement sans intervention humaine qui ralentirait le flux de livraison. L'introduction de Jidoka dans les scripts peut se faire facilement avec des tentatives multiples si un composant ne répond pas mais aussi avec des capteurs intégrés qui pourraient

• consolider le script avec des indices ou des preuves d'une erreur sur un composant intermédiaire (par exemple, une commande PING échouant sur un serveur peut confirmer qu'un widget aurait pu être affiché si le serveur avait été en service)
• informer l'opérateur qu'un script a échoué parce que le serveur n'a pas répondu, donc ni le script ni le produit n'ont échoué mais l'environnement a fait cela, ce qui évite de perdre du temps à déboguer le script.

Un manque de testabilité extrinsèque (ou du moins facilement accessible) serait également [Meaney 2018b] [Moustier 2020].

• rendre les tests plus lourds à concevoir et à exécuter
• ralentit le retour d'information, ce qui constitue un obstacle, surtout dans un environnement DevOps.
• générer des doutes et réduire la motivation et le moral

Par conséquent, une faible testabilité augmentera inévitablement le coût de la qualité et diminuera la qualité du produit.

Enfin, il arrive que l'introduction de la testabilité soit faite après coup. Cette approche présente des avantages et des inconvénients. Le pour est que l'introduction de la testabilité est toujours une bonne chose ; mais, comme tout RBA, la testabilité tardive implique souvent un remaniement lourd qui n'apporte aucune valeur ajoutée pour le client, d'où le besoin impératif d'une testabilité précoce.

Impact sur la maturité des tests

Fournir la testabilité dès que possible conduit à une qualité intégrée qui implique notamment

• Introduction de critères d'acceptation dans US pour permettre des moyens de testabilité extrinsèques ou accessibles qui pourraient être utilisés dans des scripts de test automatisés avec la pratique ATDD.
• Inclure les indicateurs avancés de SAFe dans les épopées [SAFe 2021-34], ce qui nécessitera la conception d'observables pour contrôler la qualité de la solution.
• Codage avec des modules mockables pour fournir des harnais de test
• Concevoir le produit pour permettre le test des exigences non fonctionnelles (NFR) (par exemple, mesurer les performances d'un système entièrement intégré avec des appels Internet peut ne pas fournir une bonne mesure, alors que des composants isolés aideront à repérer les véritables problèmes de performances).
• Le développement du code en TDD aidera à concevoir des unités testables.
• Mise à jour de la DoD avec des contrôles de testabilité (par exemple, la revue de code pourrait introduire un critère " Pas de dépendance implicite ").

En ce qui concerne le code legacy, il peut être utile de définir une carte de testabilité à partir d'un diagramme d'architecture. Cette carte permet de repérer les problèmes de testabilité et de dessiner une zone de confiance, tout comme l'analyse STRIDE dans la conception de la sécurité qui définit des "frontières de confiance "[Hernan 2015].

Le point de vue d'Agilitest sur cette pratique

La testabilité précoce facilitera sans aucun doute le scriptage des cas de test avec Agilitest. Cette pratique permettra d'éviter les occurrences multiples du même scénario de test, à condition de prendre en compte la partie sociale de la testabilité. Ce type de "principe de partage" est également très utile lorsqu'il s'agit de réutiliser une partie d'un script car Agilitest est capable de créer des sous-scripts avec des paramètres pour faciliter le partage des procédures de test.

En ce qui concerne l'aspect technique de la testabilité, la testabilité précoce est également la plus précieuse ; par exemple, si tous les widgets d'une page Web intègrent un certain ID, l'éditeur de script les trouvera très rapidement et il en sera de même au moment de l'exécution. Cependant, Agilitest est doté d'une IA qui trouve les widgets de manière probabiliste à partir de critères.

De plus, même si Agilitest est centré sur l'interface utilisateur sur de multiples plateformes (Windows, iOS, Mac OS, Android), il est également capable de jouer avec les services REST API qui fourniraient quelques capteurs de bas niveau pour permettre Jidoka.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.