Tests de transférabilité

Description

Aujourd'hui, il existe une grande diversité de configurations sur lesquelles les logiciels sont exécutés.

• Les navigateurs, une source majeure de problèmes de portabilité [Brown 2003], ainsi que leurs plugins 
• Normes d'affichage, résolutions et processeurs (par exemple, OpenGL, DirectX) avec différentes versions
• Systèmes d'exploitation avec un taux de création croissant 
• Matériel (mobiles, tablettes, ordinateurs portables, serveurs, ...)

Ces configurations émergent de l'évolution des technologies et des besoins du marché qui tente de s'adapter à chaque besoin. Lorsque l'on passe d'un point de vue analytique à un point de vue externe, les questions de portabilité sont rapidement en jeu [Letouzey 2012] car les utilisateurs ont des contextes différents (machines, OS, affichage, fuseaux horaires, langues et lieux, ...) qui sont amplifiés par la mobilité. Les questions de portabilité suscitent rapidement l'insatisfaction lorsque la configuration ne correspond pas à votre produit.

‍

Lorsqu'il s'agit de permettre à votre produit de fonctionner sur plusieurs combinaisons, le test de transférabilité (TT) est essentiel.

TT consiste à s'assurer que la solution est portable d'un environnement à l'autre. Il s'agit d'une NFR qui permet de répondre à la question "Sommes-nous en train de construire le bon produit ?" et, en fin de compte,"construisons-nous le bon produit ?" afin de garantir cette caractéristique décrite dans la norme [ISO 25010] :

• adaptabilité: La capacité du produit à être adapté à différents environnements sans appliquer d'actions ou de moyens autres que ceux prévus à cet effet pour le logiciel considéré.
• test de portabilité: test visant à identifier les anomalies causées par un transfert vers un ou plusieurs autres environnements, y compris les questions de temps telles que les fuseaux horaires [Letouzey 2012], et à en déduire un degré de portabilité - Parfois, la portabilité est proche de la réutilisation, mais elle implique la réutilisation d'un produit entier dans de nouveaux environnements, ce qui implique des stratégies différentes de la réutilisation de composants [Mooney 2008].
• lacoexistence: également appelée test de sociabilité ou de compatibilité, il s'agit de la capacité du produit logiciel à coexister correctement avec d'autres éléments logiciels ou matériels indépendants dans un environnement commun et partageant des ressources communes
• l'installabilité: la capacité du produit logiciel à être installé dans un environnement et connecté à des tiers déjà installés qui peuvent avoir un impact sur le logiciel installé, la possibilité de désinstallation et la durée du processus d'installation.
• remplaçabilité: La capacité du produit logiciel à être utilisé à la place d'un autre produit logiciel similaire dans un environnement donné, les caractéristiques du système devant rester inchangées après le remplacement - va de pair avec la conformité.

La remplaçabilité facilite une pratique Lean appelée SMED qui consiste à pouvoir remplacer un outil en moins de 10 minutes, ce qui facilite à la fois les activités de maintenance et les utilisateurs qui peuvent avoir besoin de changer leurs propres méthodes de travail pour s'adapter aux changements de leur entreprise.

Un logiciel est dit portable lorsqu'il peut, moyennant un effort raisonnable, être exécuté sur des ordinateurs autres que celui pour lequel il a été initialement écrit [Brown 2003]. L'histoire du développement logiciel a montré une tendance à l'augmentation des niveaux d'abstraction, des systèmes d'exploitation aux protocoles de communication (par exemple HTTP) ou aux normes et abstractions. Chaque niveau d'abstraction permet aux développeurs de se concentrer plus directement sur la résolution du problème à résoudre plutôt que sur les détails de mise en œuvre [Oglesby 2001].

Le TT est une application directe du principe " Le test est dépendant du contexte " [ISTQB 2018], ce qui signifie que chaque fois qu'il est nécessaire de changer le contexte du produit, le TT doit être pris en compte pour s'installer dans divers environnements, les utiliser et peut-être même les déplacer pour pouvoir se déplacer et s'adapter à de nouveaux environnements [Black 2015].

Impact sur la maturité des tests

Classiquement, pour faire face aux combinaisons d'environnements lorsqu'il s'agit de TT, différentes techniques de test peuvent être impliquées [Black 2015] :

• arbre de classification, 
• partitionnement par équivalence, 
• tables de décision

Toutes ces techniques trouvent une limite lorsqu'elles sont exposées à des possibilités exponentielles. Dans ces circonstances, des heuristiques doivent être ajoutées à ces techniques, le test par paire étant l'une d'entre elles. Cependant, des approches plus pragmatiques peuvent être utilisées. Les statistiques sont d'une grande aide pour permettre à l'équipe de se concentrer sur ce que le produit est le plus susceptible de rencontrer, notamment avec un diagramme de Pareto. Ces statistiques devraient être connues grâce à des études de marché permettant de comprendre le marché et les besoins et désirs des clients [Armstrong 2017]. Ces informations aident à définir la NFR liée au TT afin de produire des Epics et des User Stories pertinentes. Il est essentiel de comprendre le cas commercial ou technique pour déterminer quels compromis sont avantageux.

TT conduit alors à considérer [Mooney 2004]

• Stratégies basées sur le langage - aujourd'hui, certains langages offrent des capacités de portabilité (Java, C#, Flutter, JavaScript, ...).
• Stratégies basées sur les composants et les bibliothèques - certaines bibliothèques sont compatibles avec de nombreuses plateformes et facilitent le portage vers plusieurs environnements à la fois.
• Stratégies relatives aux systèmes d'exploitation - l'utilisation de machines virtuelles ou de cadres de virtualisation au niveau du système d'exploitation, tels que Docker ou Kubernetes, constitue un excellent exemple de portabilité.
• Stratégies d'architecture - isoler les modules dépendant de l'environnement des parties indépendantes permet de résoudre les problèmes de remplaçabilité.
• Portabilité des données - le format des données peut différer d'un environnement à l'autre, ce qui a un impact notamment sur les noms de fichiers, la compatibilité des supports, les codes de caractères, etc. ou lors de la mise à niveau d'une version, la migration des données.
• le transport des données - lorsque les données sont déplacées, elles peuvent être confrontées à des problèmes de portabilité des données, mais aussi en termes de volume notamment avec les configurations de réseau ou lorsque la transmission est soumise à des interruptions ou à des pertes de données
• Culture - (langues et lieux, adaptation à l'expérience de l'utilisateur, contraintes locales de l'environnement, ...)

Il devient alors évident que le TT doit être intégré dans toutes les activités et tous les niveaux d'idéation.

Lestests de systèmes concernent la réalisation et l'évaluation de la fiabilité dans différents environnements avec plusieurs types de TT, notamment :

• Tests d'acceptation automatisés
• Test alpha et bêta avec solution de suivi avec observables
• Test de configuration avec des méthodes classiques ou statistiques
• Tests de conformité/fonctionnels/de correction
• Test d'interface utilisateur graphique notamment avec des fermes de dispositifs internes ou des fermes publiques telles que BrowserStack ou SauceLab
• Test d'installation à l'aide de plusieurs machines virtuelles avec plusieurs configurations
• Tests de pénétration sur différentes plateformes [Salonen 2012], car les vulnérabilités peuvent différer d'une plateforme à l'autre.
• Tests de performance et de stress sur différents environnements [Salonen 2012].
• Test de récupération puisque la tolérance aux pannes peut différer et les capacités de récupération du système en ce qui concerne la sauvegarde et la restauration des données ; ainsi, différents environnements de logiciels devraient être impliqués dans le TT pour supporter "toutes" les plateformes définies.
• Test de régression avec test "Back-to-Back" qui implique deux versions différentes du logiciel qui sont soumises au même ensemble de tests et dont les résultats sont comparés.
• Test d'utilisabilité avec des services de crowdsourcing qui fournissent une sélection d'utilisateurs de test issus de différentes démographies.

Lestests d'intégration garantissent la conformité entre les parties, ce qui est facilité par les harnais de test pour effectuer des tests locaux dans une approche en sandwich où les problèmes d'intégration sont plus susceptibles de se produire ou lorsque les impacts seraient drastiques sur l'ensemble du système. Il apparaît également que la portabilité est une"exigence importante sur le plan architectural" (ASR) [Chen 2013] [Moustier 2019-1] qui a un impact énorme sur la portabilité de la solution si elle n'est pas prise en compte dès le début.

Au moment du test unitaire, la portabilité peut être utilisée de plusieurs façons :

• pour apprendre et vérifier le comportement des bibliothèques externes
• vérifier que les opérations de base fonctionnent correctement malgré les modifications de l'environnement d'exécution
• par le biais du TDD pour fournir un code robuste conçu dans un processus à pas de bébé [Salonen 2012].

Latestabilité et le TT doivent intervenir à chaque activité liée au développement du logiciel [Mooney 2008] :

• l'idéation commence lorsque les exigences fournissent des barrières de portabilité qui pourraient être inutiles ou sujettes à l'obsolescence, la portabilité ainsi que d'autres objectifs NFR qui fournissent des contraintes susceptibles d'être modifiées dans plusieurs environnements.
• au moment de la conception avec des interfaces externes qui peuvent être préservées avec les principes, les normes ou l'isolation SOLID / DDD
• au moment de la mise en œuvre avec un langage, des normes et une discipline portables
• au moment des tests, grâce à un plan de test réutilisable et à la portabilité des tests elle-même.
• au moment de la documentation, en séparant les parties dépendantes et indépendantes du système en sections distinctes ou en documents séparés et en processus de portabilité
• à maintenance temps avec des pièces réutilisables

‍

Pour établir le TT à tous les niveaux, la direction doit faciliter cette démarche car le TT, comme toute autre NFR, est principalement une question de culture [Moustier 2019-1]. Cet accent mis sur le contrôle de l'environnement de travail responsabilise les Équipes et les amène à incarner des pratiques de TT et à laisser les stratégies de TT se nourrir d'approches descendantes et ascendantes sur 3 principes [Mooney 2004] :

• Interfaces de contrôle
• Isoler les dépendances
• Pensez portable

qui est facilitée par

• Normalisation de l'interface
• Portage de "l'autre côté", notamment avec des objets factices et des simulateurs
• Traduire l'interface pour permettre des prises universelles

Le TT peut être contrôlé par des indicateurs. D'un point de vue économique, le TT se produit lorsque le coût du portage vers de multiples environnements est supérieur au coût du redéveloppement [Mooney 2008]. Idéalement, le portage devrait coûter zéro, ce qui est impossible ; par conséquent, le logiciel est caractérisé par un degré de portabilité (DP) qui peut être formalisé :

DP = 1 - (coût du port / coût du réaménagement)

Ce canevas de formule "1-A/B" peut être décliné en parties opérationnelles avec 

• "A" : le nombre d'éléments correctement utilisables après adaptation
• "B" : le nombre d'articles totaux

Par exemple, les articles peuvent faire référence à [Black 2015].

• portabilité: applicable aux structures de données, aux caractéristiques de l'environnement matériel, aux fonctions de l'environnement organisationnel, à l'environnement du logiciel du système, ou à tout autre type d'éléments. 
• Remplaçabilité: Utilisation continue des données, "inclusivité des fonctions" (c'est-à-dire les fonctions qui devraient rester inchangées après le remplacement), 
• facilité d'installation: Facilité d'installation, fonctions de relance, effort d'installation, flexibilité d'installation avec des opérations d'installation personnalisables.
• coexistence: Coexistence disponible (avec le nombre d'entités avec lesquelles le produit est censé coexister), Remplaçabilité, Utilisation continue des données (avec les éléments qui sont censés être utilisables après remplacement, comme confirmé lors de l'examen), Inclusion des fonctions
• conformité: mise en œuvre d'éléments liés à la conformité en matière de portabilité, comme confirmé lors de l'examen

En ce qui concerne la coexistence, ces problèmes se produisent principalement lorsque les groupes sont organisés en silos avec des équipes [Black 2015] qui sont soumises à la loi de Conway [Conway 1968]. Cela peut être résolu avec des équipes qui partagent les tests avec d'autres équipes de projet pour essayer d'éviter les problèmes de coexistence [Black 2015], DDD et PanTesting [Moustier 2020].

Puisque toute NFR peut être traitée progressivement, tout problème de portabilité peut en fait être renforcé par les quadrants de test agiles. En fin de compte, si les changements sont fréquents, appliquer Jidoka pour adapter ce qui n'est pas souhaitable et améliorer l'adaptabilité automatique aux changements de contexte.

Les questions de portabilité soulèvent la question des cadres indépendants et de l'architecture sous-jacente.

Le point de vue d'Agilitest sur cette pratique

Agilitest fournit une solution pour automatiser les scripts de test sur différents OS, navigateurs et mobiles. Cette capacité facilite le TT avec un changement convivial entre les interfaces de test ; cependant, ce TT est limité avec les fermes internes puisque le moteur n'est pas basé sur Selenium. Ce moteur est publié sur github sous une licence Apache-2.0 [Pierrehub2b 2021] qui permet d'exécuter des scripts de test de conformité sans frais ; cependant, il n'est pas encore inclus dans les fermes publiques pour un TT massif. Agilitest est donc une bonne solution intermédiaire pour commencer le TT avec des solutions de tests internes.

‍

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

‍