Tests de compatibilité

Que sont les tests de compatibilité ?

Les tests de compatibilité (CT) ont lieu lorsque la solution est mise à la disposition des utilisateurs finaux (UE) sur différentes plateformes qui peuvent modifier l'expérience de l'UE.

Le CT vise à évaluer ces altérations sous plusieurs configurations possibles, telles que différentes : 

• Navigateurs,
• Bases de données,
• Systèmes d'exploitation (OS),
• Appareils mobiles,
• Réseaux,
• Appareils,
• ...

avec différentes versions et combinaisons ; l'exemple classique utilisé pour le TC est la compatibilité avec les navigateurs ou les mobiles. La solution livrée doit être testée sur les principales plateformes et versions. 

Pour y parvenir, il existe 2 types de CT :

• le test de compatibilité ascendante (BCT) : il garantit que les nouvelles versions fonctionneront toujours sur les anciennes versions des plates-formes
• le test de compatibilité avancée (FCT) : il permet d'évaluer si les prochaines versions des plateformes supporteront toujours les versions actuelles ou nouvelles de la solution.

La plate-forme sur ou dans laquelle le composant est installé peut différer en termes de :

• Matériel - le composant déployé peut fonctionner sur différents types de dispositifs tels que des ordinateurs portables, des téléphones mobiles, des tablettes, ainsi que des logiciels intégrés, éventuellement sur des puces.
• Logiciel - le composant livré peut s'appuyer sur des éléments logiciels existants tels qu'un système d'exploitation, un navigateur, une API à laquelle le composant doit se conformer.
• Réseau - les nombreux composants déployés communiquent par certains moyens, notamment le matériel, les logiciels et les protocoles avec différents paramètres.

‍

L'impact de la plateforme commence dès l'installation qui peut être assistée par des processus, éventuellement automatisés.

Impact sur la maturité des tests

Le processus d'installation est une conséquence directe de l'EC car les plateformes ciblées influenceront le déploiement. Une fois automatisé, ce processus d'installation devrait intégrer des vérifications qui devraient empêcher les configurations non supportées. C'est l'une des tâches de vérification qui devrait être incluse dans un pipeline de"Déploiement continu". 

Dans un environnement DevOps, il s'agit de mettre à jour en même temps les environnements ciblés, le processus d'installation, le CT et les composants livrés.

‍

Par conséquent, l'ensemble de l'équipe doit connaître les 4 parties pour savoir comment gérer chacune d'entre elles.

• au niveau de l'environnement, l'équipe doit
  - mettre en place l'environnement
  - définir les nombreuses versions acceptées de la plate-forme
  - interagir avec la plate-forme
  - remarquer ses comportements par le biais des interfaces disponibles 

• au niveau de l'installation, pour
  - définir et configurer le processus d'installation qui peut éventuellement être automatisé
  - tester le processus d'installation contre les nombreuses versions acceptées de la plate-forme

• au niveau de la CT, pour
  - définir les actifs à soumettre à la CT et tester le produit livré par rapport aux versions acceptées de la plate-forme
  - limiter la configuration possible notamment grâce à une analyse Pareto
  - définir toute CT automatisable pour la BCT et la FCT

• au niveau des composants, à
  - préparer le TC avec certains éléments de testabilité pour la qualité intégrée [SAFe 2021-26][SAFe 2021-27]
  - inclure certaines hypothèses de variabilité dans la conception

Naturellement, cela renforce la nécessité de responsabiliser l'ensemble de l'équipe sur la qualité du produit.

Pour compléter la vue d'ensemble de la maturité du TC, vous devez également comprendre que les plateformes peuvent dériver différents niveaux de TC grossièrement modélisés en 4 niveaux :

• Réactif: l'environnement est découvert en même temps que l'ingénierie des composants à livrer - cela se produit lors de la création des prototypes - les problèmes de compatibilité sont rencontrés principalement lors du déploiement du produit.
• Ad hoc : Ces parties sont combinées de manière ad hoc - le TC est motivé par la conformité à un objectif unique, la fabrication du produit - les problèmes peuvent être découverts pendant la phase de développement.
• Spécifié: lorsque des conventions doivent être établies entre plusieurs équipes ayant des dépendances - des modèles de conception architecturale sont proposés pour échelonner l'utilisation de l'environnement.
• Normalisé: lorsque le domaine est suffisamment mature, des normes et des certifications émergent du commerce - l'environnement est protégé contre les abus connus et les problèmes habituels - ce niveau peut atteindre des dispositions légales qui peuvent différer d'un pays à l'autre - Parfois, lorsqu'un protocole a été établi, des plugfests sont organisés pour améliorer la compatibilité entre les vendeurs.

Niveaux de CT

Les niveaux décrits ci-dessus mettent en évidence une stratégie de test possible de type Shift Left (SLT) en analysant les exigences de la plate-forme et de l'environnement pour définir les nombreuses configurations de plate-forme auxquelles les utilisateurs finaux seront confrontés. 

Pour fournir de multiples retours sur le TC, il faut également inclure des techniques de Shift Right Testing (SRT), notamment grâce aux Alpha et Beta testing, Dark ou Canary Releasing pour réaliser des crowd testing [Leicht 2017] et obtenir des retours du terrain. Cependant, le SRT est possible lorsque le produit livré n'est pas soumis à des certifications.

Une tentative exhaustive d'aborder la question de la compatibilité pourrait consister à :

• Partir d'un diagramme de déploiement.
• Identifier les nombreux actifs (appareils, serveurs, armoires, bases de données, réseaux, dispositifs d'affichage, ...) et les systèmes d'exploitation.
• Établir une liste des biens et des systèmes d'exploitation en fonction des versions disponibles et du nombre d'occurrences sur le terrain.
• Définir pour chaque partie sa valeur ajoutée afin de prioriser l'effort de test.
• Proposer une stratégie et un plan d'action ainsi que des budgets.

Parmi les nombreuses stratégies possibles, il y en a quelques-unes qui émergent souvent avec une approche de test basée sur le risque, comme le ciblage : 

• Scénarios de CT significatifs pour couvrir les pièges spécifiques à la plateforme.
• Une stratégie "mobile first" met l'accent sur la compatibilité avec les plates-formes mobiles afin de découvrir les problèmes spécifiques à ces dernières.
• Respect de quelques partenaires ou protocoles stratégiques.

Cette approche en cascade doit être découpée en plus petits morceaux pour s'adapter à des méthodes alternatives et légères, par exemple :

• aborder les problèmes au fur et à mesure qu'ils apparaissent dans une approche simple et réactive
• aborder n'importe quelle phase d'un quadrant de test agile par sprint [Marick 2003][Crispin 2011][Bach 2014][Crispin 2021] pour permettre de telles pratiques de test petit à petit afin d'aider l'équipe à améliorer ses compétences dans ce NFR
• appliquer le principe de subsidiarité et décentraliser la prise de décision avec l'aide de la direction pour optimiser l'effort d'essai
• appliquer l'ingénierie des systèmes basée sur les modèles(MBSE) [SAFe 2021-19] [Moustier 2020] [Galiber 2019], en particulier si le système est énorme ou monolithique et qu'il nécessite une vision globale au niveau du produit.

Le point de vue d'Agilitest sur cette pratique

Dans le but d'aider le CT, Agilitest fournit des moyens d'automatisation capables de se brancher sur différents types d'applications et de dispositifs au moment de la conception du script, tels que les :

• Applications mobiles (iPhone et Android)
• Applications HTML (tout navigateur peut être sélectionné)
• Applications de bureau pour MS Windows OS
• Backends API REST / SOAP

La limitation actuelle est l'environnement ciblé par le test qui doit être atteint à partir des services d'injection sous lesquels Agilitest doit être installé. Cette contrainte désactive les fermes publiques de mobiles et de navigateurs telles que SauceLab ou BrowserStack et favorise un laboratoire de test qui héberge des appareils et des navigateurs HTML, éventuellement avec une stratégie BYOD pour faciliter le flux bien que cela crée quelques problèmes GDPR.

‍

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

‍