En quoi consistent les tests de système ?

Imaginez que vous observiez un système logiciel au microscope, en commençant par le niveau de grossissement le plus extrême, à savoir l'unité. Il s'agit de l'élément de base du système logiciel. La vue s'élargit ensuite vers l'extérieur pour inclure le niveau d'agrandissement suivant, à savoir les modules créés par ces unités individuelles. Enfin, en dézoomant complètement, vous arrivez au niveau du système. À ce niveau d'agrandissement, vous pouvez voir tout ce qui se trouve dans le système et comment tous les composants créés par ces modules fonctionnent ensemble.

D'une certaine manière, les tests système s'apparentent à cette vision microscopique, mais avec une différence essentielle. Les tests système sont une forme de tests boîte noire, ce qui signifie que les testeurs s'intéressent moins à la vision des composants impliqués dans son assemblage qu'à la fonctionnalité globale du système. Dans cette perspective de « réussite/échec », le comportement du système n'est remarquable dans ce contexte que dans la mesure où il est lié aux performances du système. (Les tests en boîte blanche permettent de mieux comprendre la nature des composants d'un système.)

Les tests de systèmes impliquent souvent l'analyse de plusieurs systèmes logiciels distincts qui peuvent ou non fonctionner à l'unisson au sein d'un système logiciel particulier.

Considérons le compte à rebours qui précède les lancements spatiaux. Si tout le monde se souvient du compte à rebours dramatique en 10 temps qui précède l'allumage et le décollage, peu se rappellent les nombreuses vérifications demandées par le chef de vol et auxquelles il répond par l'affirmative en donnant son feu vert. Lors d'un lancement spatial classique, les chefs de département sont consultés sur les opérations prévues, la sécurité de la mission, les systèmes du véhicule et les conditions météorologiques attendues, parmi de nombreux autres sujets. Chaque département est interrogé et chaque chef de département répond à son tour.

De même, les tests de systèmes peuvent être considérés comme la chacklist finale qui précède le lancement d'un nouveau système logiciel. La dernière phase de correction des bogues logiciels connus a été achevée. À l'instar des checklists historiques créées par les pionniers de l'espace, tout repose désormais sur le feu vert final de chaque « département » impliqué dans les tests du système.

Chaque requête est ombrée en fonction de la fonctionnalité du système :

• Chaque composant fonctionne-t-il comme prévu ?

• Les composants fonctionnent-ils en bonne coordination les uns avec les autres ?

• Le logiciel est-il prêt à offrir une interface utilisateur fluide et à fournir l'expérience utilisateur (UX) souhaitée ?

Lorsque nous parlons de tests de systèmes, nous rencontrons naturellement le sujet des dépendances, qui sont des relations qui existent entre les cas de test. Dans de telles situations, le résultat d'un cas de test peut dépendre partiellement ou entièrement des résultats d'autres cas de test. Les dépendances peuvent également concerner la fonctionnalité, les environnements de test ou les politiques de sécurité, et peuvent même avoir un impact sur l'ensemble du processus de test mis en place par une entreprise.

Les méthodologies de test des systèmes ne permettent pas d'examiner en détail leur fonctionnement interne (rappelons qu'il s'agit d'une forme de test boîte noire), mais elles permettent de déterminer si une application particulière fonctionne correctement. L'idée était de tester le système afin de détecter les lacunes, les erreurs ou les exigences manquantes, car cela détermine la fonctionnalité globale de l'application logicielle.

Les tests système sont généralement effectués après l'integration testing, mais avant les tests d'acceptation, afin de garantir que tous les composants fonctionnent correctement ensemble. Comme nous le verrons, ils englobent souvent à la fois les aspects fonctionnels et non fonctionnels du système. Parce qu'ils reposent à la fois sur des domaines strictement fonctionnels et non fonctionnels, ils couvrent des aspects aussi vastes que l'intuitivité, la sécurité et les performances.

L'un des principaux objectifs des tests de système est de vérifier que le langage de codage d'un logiciel peut être traduit en un programme utilisable. Cependant, l'objectif principal des tests de systèmes est de s'assurer que le logiciel évalué répond aux exigences professionnelles des utilisateurs qui s'en serviront.

Le processus de test est censé refléter le même environnement de production que celui qui sera utilisé, afin de garantir que le logiciel fonctionne comme il se doit malgré l'évolution des conditions réelles. De même, les données de test sont créées pour imiter des données et des situations réelles. Une fois les tests effectués, les défauts du logiciel peuvent être localisés et corrigés.

Les tests de systèmes peuvent être classés dans l'un des trois groupes principaux. Le premier, le functional testing, s'intéresse à la performance du système, mais ne cherche pas de réponse plus approfondie que de savoir si le logiciel fonctionne comme promis. Voici quelques-uns des principaux types de functional testing :

• Tests d'acceptation : les tests d'acceptation par l'utilisateur visent à intégrer les tests de performance effectués par les personnes qui représentent la population visée par le logiciel en cours de production. Ces utilisateurs apportent une touche de réalisme au processus de test en testant le logiciel en conditions réelles.

• Integration testing : un domaine crucial du functional testing consiste à étudier la manière dont différents modules ou composants s'intègrent lorsqu'ils sont contraints de fonctionner en étroite collaboration. C’est l'integration testing. Un système entièrement intégré permet aux testeurs d'évaluer les principales interactions.

• Tests de fumée : kes tests de fumée permettent de vérifier si la fonctionnalité globale a été maintenue après qu’un développeur a effectué une modification de code. La modification a été apportée et les tests de fumée vous permettent de voir rapidement s’il y a des effets indésirables résultant de cette modification.

• Tests unitaires : dans les tests unitaires, une section limitée du code est vérifiée dans un environnement de test isolé. Si l’unité en question échoue à son test (comme le montre la comparaison des données de test et des objectifs de fonctionnalité), davantage de tests individuels de composants ou modules sont généralement nécessaires au niveau du système.

Bien que les tests fonctionnels fournissent des informations extrêmement importantes, ces données sont en gros limitées à un vote pour ou contre basé strictement sur le fait que le système fonctionne comme il le devrait. Cela ne tient pas compte d'un grand nombre de variables pertinentes, telles que la sécurité du système, l'interface utilisateur et les performances.

Les tests de systèmes non fonctionnels permettent d'évaluer le fonctionnement du système. La différence essentielle entre le functional testing et le non-functional testing peut se résumer à la comparaison suivante :

• Functional testing : le système fonctionne-t-il ?

• Tests non fonctionnels : le système fonctionne-t-il correctement ?

Dans cette optique, voici quelques-unes des principales formes de non-functional testing du système :

• Test d'accessibilité : le contenu numérique présenté est-il accessible à tous, y compris aux personnes souffrant de handicaps divers ? Les tests d'accessibilité examinent cette question et visent à garantir que le contenu est communiqué à tous les utilisateurs potentiels, de manière à surmonter les handicaps physiques et mentaux et à assurer la conformité avec les normes d'inclusion établies par l'Americans with Disabilities Act (ADA).

• Tests de compatibilité : lorsque l'on considère l'étendue de la distribution des applications et le nombre de plateformes sur lesquelles elles doivent fonctionner, on comprend facilement la nécessité des tests de compatibilité, qui évaluent le bon fonctionnement de ces applications, quel que soit le nombre de réseaux, de navigateurs, de systèmes d'exploitation et de configurations matérielles sur lesquels elles doivent fonctionner.

• Tests de charge : dans une sous-discipline qui traite de la physique unique présentée par la notion de charge et de son impact sur la capacité d’un système à traiter les requêtes système, les tests de charge se concentrent sur ce qui se passe lorsque l’évolutivité se produit à grande échelle. Nous supposons que le système n’aura aucun problème à traiter une seule requête système, mais qu’en est-il lorsque cette charge est multipliée par des milliers de requêtes, voire beaucoup plus ?

• Tests de localisation : il s'agit d'une économie mondiale à laquelle participent plus de pays et de cultures que jamais auparavant. Les tests de localisation consistent à s'assurer que le contenu d'un logiciel exporté vers différents pays du monde est adapté à cette zone spécifique, conformément aux règles générales concernant l'interface utilisateur.

• Test de performance : ce type de test non-functional testing porte une attention particulière aux problèmes de performance. Par exemple, il est essentiel pour une bonne performance qu'un système réponde aux demandes rapidement et sans heurts. Le protocole de test dans le cadre des tests de performance évalue le temps d'attente des utilisateurs pour le traitement des requêtes.

• Tests de sécurité : ce n'est un secret pour personne : de nos jours, la sécurité des données revêt une importance primordiale. Il est donc logique qu'une forme de test porte spécifiquement sur la sécurité. Les méthodes de test de sécurité sont sélectionnées en fonction du type de menaces potentielles auxquelles l'entreprise est exposée.

• Tests de résistance : tout comme un test de résistance médical vise à évaluer le fonctionnement du cœur d'une personne sous l'effort, un test de résistance logiciel permet de vérifier la résilience opérationnelle d'un système lorsqu'il est poussé au-delà de sa capacité normale afin de détecter les goulots d'étranglement et les vulnérabilités.

• Tests d'utilisabilité : ce type de non-functional testing porte entièrement sur la qualité de l'expérience utilisateur (UX). Le test d'utilisabilité est un processus de test manuel qui est généralement utilisé à petite échelle. Néanmoins, il est recommandé de l'appliquer fréquemment, en particulier lors de la réalisation d'opérations complexes telles que la localisation d'applications.

D'autres types de tests du système sont utiles, même s'ils n'entrent pas dans les catégories des functioning ou non-functioning tests. Voici quelques-unes des méthodologies les plus remarquables :

• Tests d'API : les interfaces de programmation d'applications (API) sont extrêmement importantes, car elles permettent le développement de logiciels en aidant différentes applications ou systèmes à se connecter. Les tests API garantissent que les points de connexion API fonctionnent comme prévu. Ils assurent également la supervision des autorisations des utilisateurs et de la manière dont les données sont gérées via les API.

• Tests automatisés : comme son nom l'indique, le test automatisé (également appelé automatisation des tests) met la puissance de l'automatisation au service du test des applications logicielles. Pour ce faire, il crée et utilise des scripts de test conçus pour effectuer des tests sur des applications logicielles, ce qu'il fait à grande échelle, sans intervention humaine. Les ensembles structurés de directives, d'outils et de pratiques qui permettent d'automatiser le processus de test sont appelés cadres des exigences.

• Tests manuels : en opposition directe avec les tests automatisés, les tests manuels s'appuient sur des tests humains pour expérimenter le logiciel évalué, guidés par divers scénarios et scripts de test. Les testeurs sont encouragés à mettre le logiciel à l'épreuve afin d'identifier les problèmes nécessitant une résolution.

• Tests de migration : les organisations qui mettent à jour ou transforment leur culture numérique d’entreprise ont besoin de tests de migration. Lorsque les entreprises s'engagent dans de tels efforts de transformation, elles doivent s'assurer que les données et les logiciels clés sont correctement transférés d'un système sortant à un système entrant.

• Tests de régression : bien que les modifications du code aient pour objectif d'améliorer le logiciel ou d'en renforcer les capacités, elles peuvent involontairement créer des difficultés si des erreurs humaines viennent s'y ajouter. Les tests de régression permettent aux testeurs de confirmer un fonctionnement stable et correct en réexécutant les tests si nécessaire.

Bien que le processus de test système offre les tests de performance en boîte noire les plus complets qui soient, la réalisation de tests système n'est pas sans poser certains problèmes potentiels :