Après les tests fonctionnels et les tests de performance au sens ISO – 25 010, je m’attaque dans cet article à la famille des tests de compatibilité au sens de l’ISO – 25 010 afin de savoir exactement à quoi correspond la « compatibilité » dans le cadre de la qualité logicielle.
Pour avoir plus d’informations sur la norme ISO – 25 010, je vous invite à lire ou relire mes autres articles sur le sujet.
Les tests de compatibilité sont une famille de tests dont on parle peu, néanmoins ils sont à l’origine de nombreux bugs et de rejets d’application qui, à priori, semblaient très efficaces. Quel est l’intérêt d’avoir un logiciel parfait si ce dernier ne peut pas fonctionner dans son environnement d’utilisation ?
Les tests de compatibilité ont pour but de vérifier cela au moyen de 2 types de tests, les tests de coexistence et d’interopérabilité.
Comme vous pouvez le voir avec l’image ci-dessus, la famille des tests de compatibilité contient, d’après la norme ISO – 25 010, 2 types de tests spécifiques, chacun ayant un rôle bien définit :
- Les tests de coexistence
Les tests de coexistence servent à évaluer le degré d’un logiciel à réaliser ses tâches en étant intégré dans un environnement avec d’autres logiciels, produits sans en être impacté d’un point de vue qualité (fonctionnalités mais également non-fonctionnels).
Avoir un logiciel qui ne fonctionne que dans l’environnement de développement ne sert à rien. De plus avec la multiplication des applications (qui sont souvent exécutées en parallèle) ces tests deviennent de plus en plus importants.
Imaginons un logiciel de domotique qui permette de gérer la chaleur de notre maison en gérant le chauffage et la climatisation mais aussi l’ouverture et la fermeture des volets. Ce logiciel peut parfaitement fonctionner en étant seul mais s’il utilise des ondes qui entrent en conflit avec d’autres ondes « ménagères » comme le Wifi, il se peut que son utilisation soit perturbée par l’utilisation d’internet par un membre de la famille.
Les tests de coexistence sont justement là pour éviter ce genre de problème.
Un moyen d’effectuer ces tests à moindre coût est la réalisation de bêta test (car en environnement client), notamment avec des campagnes de Crowdtesting. Dans tous les cas, dès lors où le logiciel devra être utilisé sur un périphérique qui exécutera d’autre applications, il faut penser à ces aspects et si nécessaire dédier des tests sur ce point. Un logiciel peut parfaitement fonctionner si elle est seule dans son environnement mais beaucoup moins bien si d’autres applications consomment des ressources ou font appel à un service commun.
- Les tests d’interopérabilité
Les tests d’interopérabilité sont là pour assurer que les informations entre 2 (ou plus) systèmes et composants sont bien échangées.
Un testeur prévoit ses tests en pensant aux différentes parties prenantes. Pour ces raisons les API sont testées, ces API peuvent appeler d’autres API et cet enchaînement doit être « compris » par l’ensemble des éléments de la chaine. Si ce n’est pas le cas l’application peut rencontrer des problèmes majeurs en production alors que fonctionnellement elle se comporte parfaitement.
Ce n’est pas parce que le logiciel trouve et transmet la bonne information que cette dernière est bien analysée par un autre système. Par exemple, on peut enregistrer un texte puis l’encoder UTF-8 pour le transmettre. Si le logiciel qui reçoit le texte envoyé ne comprend que le code ASCII il y aura alors des problèmes d’interopérabilité et le texte « envoyé » ne sera pas le texte « reçu ».
Les tests d’interopérabilité sont présents pour détecter ces potentiels problèmes.
Merci à Emile Dintzer pour son aide dans l’écriture cet article
Source ISO – 25 010
Syllabus ISTQB fondation 2018 Lien anglais car non disponible en français à la date d’écriture
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
3 Responses
Merci pour cet article mais j’ai du mal à comprendre le schéma/
il y a d’autres types de test à mes yeux , les tests béta , de bout en bout, exploratoires …
Pourquoi n’apparaissent t’ils pas sur le schéma ?
Merci
Bonjour Thomas,
Merci pour ce retour dont voici la réponse:
attention, les tests dont vous parlez n’ont pas de liens direct avec les familles de tests liées à l’ISO-25010.
On peut en effet faire des tests de compatibilité en bout en bout (sur un système complet), en exploratoire (en variant les environnements de test), en bêta (avec de crowdtesting)… Il en est de même avec les niveaux de test.
Je travaille actuellement sur un article permettant de mieux situer ces test.