Introduction

Sur une grosse majorité des projets rencontrés, il s’avère que les tests non fonctionnels sont éludés. À l’évocation de cette catégorie de test, un soupir sonore « Aaaaah » un peu gêné est en général l’unique Exigence Non Fonctionnelle (ENF ou NFR en anglais - Non Functional Requirements) connue de tous. Dans certains cas, on aura des tentatives telles qu’un essai de l’application sur X navigateurs différents ou une équipe spécialisée qui fait des tests de charge ou de sécurité.

Les anomalies ne proviennent des fonctionnalités qu’à hauteur de 16 % [Beizer 1994], mais si certaines contraintes rencontrées en exploitation ne sont pas respectées, le produit ne sera qu’un prototype ou une expérience de laboratoire. C’est pourquoi une stratégie de test ne doit pas faire l’économie de tests non fonctionnels avec une prise en compte dès la conception.

Exigences non fonctionnelles dans la mobilité

Dans le domaine de la mobilité, il existe une ENF connue de tous : l’énorme choix de combinaisons OS/Version/Matériel et si l’utilisation du produit sur différentes plateformes mobiles n’est pas prise en compte dès le début, on risque de développer...

Tests de sécurité

Depuis le 26 mai 2018, l’Europe a promulgué une loi (RGPD - voir plus bas dans ce chapitre) pour lutter contre le faible niveau de sécurité lié au traitement et à la protection des données personnelles. Cela a fait beaucoup de bruit au vu des sanctions annoncées (https://fr.wikipedia.org/wiki/R%C3%A8glement_g%C3%A9n%C3%A9ral_sur_la_protection_des_donn%C3%A9es) et n’est qu’un prétexte de plus pour mettre au centre des préoccupations les tests de sécurité déjà abordés par l’industrie des cartes bancaires [PCI-DSS], l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui a produit le « Référentiel général de sécurité » [RGS] des standards internationaux de sécurité [ISO27002] ou encore ceux liés aux sociétés cotées en bourse [SAS70].

Cette section se penche avec ambition sur un domaine souvent obscur.

1. Généralités sur les tests de sécurité

La sécurité est un domaine des plus vastes, car il touche toutes les parties du produit et les personnes qui interagissent avec. Cette configuration fait du test de sécurité :

une activité pluridisciplinaire avec des Experts qui comprennent les règles, les lois, l’organisation sous-jacente, les opérations, les processus et les technologies utilisées ;
une exploration des dangers dans l’obscurité avec pour seul éclairage l’expertise afin de trouver les failles avant qu’elles ne soient exploitées ;
une activité de contrôle perpétuel des failles connues pour éviter qu’elles n’impactent (à nouveau) le système ;
une tâche qui ne saurait être simple…

Le MVP pour les tests de sécurité

Ce sujet est très difficile à aborder, car techniquement complexe, culturellement ambitieux et politiquement délicat. Aussi, comme à chaque fois avec l’agilité, on tentera d’identifier le MVP de la sécurité ; ce MVP peut être complètement empirique (on fait avec les moyens et la connaissance du bord), sous-traité...

Tests d’utilisabilité

À force de voir la même application, l’équipe de réalisation a pris des habitudes pour effectuer ses tests, ce qui la rend relativement aveugle à la convivialité de l’application. Les tests d’utilisabilité permettent de prendre du recul sur l‘impression que laisse le produit mis à disposition.

Ce genre de test permet :

lorsque le produit est à usage professionnel, de faciliter l’adoption, la formation, l’efficacité opérationnelle et de prendre soin des conditions de travail des utilisateurs ;
lorsque le produit est destiné à des clients, de faciliter le taux de conversion (voir la Qualité de Service - section Processus d’Intégration Continue (PIC) du chapitre Versant technique du test).

1. Le test du Magicien d’Oz

Figure 20 : Les acteurs du Magicien d’Oz

Lisa Crispin présente ce type de test pour renforcer l’UX (User eXperience - c’est l’expérience utilisateur avec le produit) au moment de la conception d’une fonctionnalité en reprenant l’histoire du Magicien d’Oz (voir https://fr.wikipedia.org/wiki/Le_Magicien_d%27Oz_(film,_1939)). Dans cette comédie musicale hollywoodienne qui a marqué profondément la culture américaine, on voit une personne qui manipule toute une machinerie qui anime le fameux Magicien d’Oz.

Dans le Test du Magicien d’Oz, on utilisera une maquette (même en papier) face à un utilisateur avec le concepteur qui, comme le Magicien d’Oz, va afficher les changements [Crispin 2009].

Par cet artifice, on pourra juger de l’utilisabilité d’un produit.

Cette technique pourra aussi être utilisée pour mieux comprendre la cinématique d’une fonctionnalité.

2. L’Experience Map

L’Experience Map est un outil couramment utilisé en marketing [Gronier 2016]. Elle procure une vision complémentaire et dynamique aux persona car elle :

favorise la recherche de solutions ;
permet d’identifier les actions critiques pour l’utilisateur ;
génère des opportunités de conceptions pour les phases suivantes (pour les futurs utilisateurs) ;
donne une vision plus dynamique sur la relation entre une persona et le produit.

Guillaume...

Tests de charges

La catégorie des tests de charges exploite une technique relativement simple : effectuer une même action lancée en parallèle (comme par autant d’utilisateurs) avec plus ou moins de force (la charge). On va ainsi constituer des « tirs » :

pour mesurer la réaction du système en fonction du nombre d’utilisateurs et trouver ainsi la charge limite qui répond aux exigences de temps de réponse ;
pour éprouver la robustesse du système en trouvant son point de rupture (la charge maximale) ;
pour identifier l’endurance du système en le soumettant à une charge constante pendant plusieurs heures.

Tests de robustesse et piratage

Les tests de robustesse permettent d’observer le comportement de l’architecture dans la situation où le système n’est plus en mesure de réagir à une demande supplémentaire d’un utilisateur ; dans certains cas, le service s’arrête et revient à l’OS en y donnant alors un accès direct, dans d’autres cas, les données sont alors poussées sur la pile d’exécution et sont considérées comme des instructions (voir TOCTOU/Spoofing - section Analyse de failles de sécurité sur le design et le code). C’est pourquoi cette technique est utilisée pour pirater un système et récupérer des informations, faire planter le système ou en prendre complètement le contrôle.

Les tirs se déroulent en plusieurs phases :

définition du tir, notamment :

son objectif,
l’action à charger,
les données nécessaires aux tir,
les outils et les machines impliquées,
le produit sur lequel le tir aura lieu.

développement des scripts et configuration des outils ;
constitution des données ;
contrôle de l’environnement de test : étant donné qu’un tir peut durer des heures, il est nécessaire de vérifier que les données, fonctionnalités et serveurs sont opérationnels, par exemple en effectuant un smoke test pour limiter les mises au point des scripts et données ;
exécution du tir et mises au point éventuelles des scripts et des données - pour...

Tests de migration ou reprise de données

1. Généralités sur les Migrations

La migration peut avoir lieu à tous les niveaux :

l’emplacement géographique de l’infrastructure ;
le changement des serveurs ;
le changement d’OS ;
le changement de base de données ;
le changement de technologie ;
le changement de framework de développement ;
le changement fonctionnel.

Chaque situation méritera de définir un plan d’attaque de la migration avec notamment :

son périmètre ;
une analyse des risques ;
un calendrier ;
le mode de bascule (Big Bang, par secteurs, ZDD (voir chapitre Versant technique du test - section Processus d’Intégration Continue (PIC))) ;
un plan de secours ;
un moyen de test qui vérifie que la migration n’a pas affecté négativement le service.

Le moyen de test (notre sujet) sera conçu suivant le modèle des tranches d’emmental.

Le Programme SIRHEN

Le Système d’Information de gestion des Ressources Humaines de l’Éducation nationale est un programme de migration qui avait été poussé par la DSI pour répondre notamment à la désuétude du framework de développement Informix (https://fr.wikipedia.org/wiki/Informix) qui datait des années 80. Le programme démarra en 2007 avec un budget de 60 millions d’euro ; entre temps, il a inclus de nouvelles fonctionnalités poussées par le métier, ce qui a conduit à une refonte des nomenclatures, du schéma de la base de données et de la base de données elle-même ; les années passant, les Développeurs ont aussi procédé à des mises à jour technologiques avec différentes plateformes utilisées (ex. Angular (cette plateforme vient aussi bousculer l’automatisation des tests qui pousse l’utilisation de la librairie Protractor (https://www.protractortest.org) plutôt que Selenium.)) ; l’organisation du programme s’est aussi restructurée pour intégrer l’agilité à l’échelle avec SAFe. Aujourd’hui, cette migration a coûté à l’État 0,5 milliard d’euros...

Tests de tolérance aux pannes

La tolérance est un compoement du srtystème qui a inclus dès sa conception un comportement qui reste acceptable, même en cas de problème. Cet attribut est indispensable sur les systèmes critiques tels que :

les systèmes qui nécessitent qu’une information soit transmise comme les calculateurs embarqués dans les avions ou les télécommunications à usage militaire qui doivent obtenir la bonne information même en cas de défaillance ou d’erreur de transmission ;
les systèmes où la disponibilité est critique comme les systèmes de secours (ex. la mise en route automatique d’un groupe électrogène) ;
les systèmes qui subissent une dégradation progressive du matériel que le logiciel vient compenser jusqu’à ce qu’il renseigne à l’avance sur le remplacement nécessaire des pièces ;
les systèmes qui subissent des perturbations éventuellement brutales de l’environnement avec une stabilisation automatique pour que les conditions internes du système soient viables.

Ces systèmes ont en commun :

une identification au plus tôt de la criticité et du facteur de défaillance ;
le mécanisme de déclenchement du système de secours : une conception résiliente qui répond à cette situation jugée inacceptable et les moyens (souvent élevés) pour faire face à la défaillance à venir ;
une instrumentation et une mise en condition pour tester le bon fonctionnement du système de secours.

1. Facteurs de défaillance

Une approche de type 5M (https://fr.wikipedia.org/wiki/Diagramme_de_causes_et_effets) permet d’examiner à 360° les différents facteurs de défaillance d’un système, à savoir :

la Matière première : ex. l’information ;
le Matériel : l’infrastructure ;
la Méthode : les usages du SI et les services ;
la Main-d’œuvre : les Ops ;
le Milieu : l’environnement d’exploitation.

Les sections qui suivent fournissent les situations les plus courantes de défaillances dans quelques-uns...

Tests d’exploitabilité

Suivant les cultures, ce test est aussi appelé VABE (Vérification d’Aptitude à la Bonne Exploitabilité) ou VAE (Vérification d’Aptitude à l’Exploitabilité).

L’objectif des Tests d’exploitabilité est de vérifier que le niveau de qualité de service pour une mise en production est suffisant et couvre généralement :

la documentation nécessaire (ex. : codes d’erreurs, analyse des journaux, moyens d’accès…) pour que l’équipe de support utilisateur puisse avoir les informations suffisantes pour jouer son rôle ; si nécessaire, une présentation, voire une formation, sera dispensée à cette équipe pour que sa connaissance et son savoir-faire soient assurés ;
les tests de déploiement et de retour arrière (rollback) ont été réalisés sur des environnements les plus proches possible de la production ;
la vérification que les tests de charges ont des résultats compatibles avec les niveaux attendus en production ;
la vérification que le niveau de sécurité est en conformité avec les attentes des Ops ;
la vérification des moyens de supervision (mise à jour des outils de vérification des services réguliers) ;
la vérification...

Tests de traçabilité

1. Périmètre

La traçabilité est un élément qui est réglementaire sur les systèmes et produits où des vies humaines sont en jeu comme dans le domaine médical ou l’aéronautique. Dans d’autres contextes, elle apparaît aussi comme incontournable lorsque les coûts liés à une mauvaise gestion des impacts d’une anomalie plane au-dessus du projet.

Traçabilité des lots

Un des projets sur lesquels j’ai été impliqué mettait en œuvre le logiciel et le matériel liés à des Set-top box (https://fr.wikipedia.org/wiki/Set-top_box) (STB). Notre entreprise passait par un intégrateur en électronique qui fournissait les moyens d’assemblage de nos produits. Afin de limiter les frais colossaux qu’un retour de masse des STB pouvait engendrer en cas de problème matériel, il a fallu mettre en place un système de traçabilité qui permettait la mise en correspondance entre :

le numéro de série de chaque STB ;
les numéros de lots de chaque carte mère ;
les numéros de lots de chaque composant ;
la version du firmware (logiciel flashé à l’usine) ;
la version des plans électroniques et les références fournisseur de chaque pièce mécanique (la BOM - Bill of Materials - la nomenclature du produit (https://fr.wikipedia.org/wiki/Nomenclature_(logistique)).

La traçabilité mise en place devait permettre d’identifier les numéros de série des STB impactées à partir des lots de parties défectueuses.

Dans le seul domaine logiciel, la notion de traçabilité n’inclue généralement pas le numéro de série des parties matérielles, car le risque est largement plus faible, mais on comprend que dans l’absolu, la fiabilité de la solution mise en exploitation dépend des versions de tous les composants logiciels et matériels : c’est la notion de Baseline.

Gestion de configuration vs Gestion de versions et Baseline

La gestion de configuration est un ensemble de pratiques pour gérer la description et les modifications d’un système et de ses parties. Chaque...

Tests de sûreté de fonctionnement

La sûreté de fonctionnement est la combinaison de différents facteurs [Laprie 1996] :

la fiabilité : ce point peut être couvert notamment par :

l’exactitude fonctionnelle (attestée par les tests fonctionnels) ;
la tolérance aux pannes ;
l’utilisabilité ;
la durabilité ;

la maintenabilité ;
la disponibilité et les temps de réponse ;
la confidentialité ;
l’intégrité : impossibilité d’altération des informations ;
la sécurité et l’innocuité : absence de conséquences catastrophiques - la prévention des incidents graves issue d’une analyse de risques.

Dans un premier temps, on peut percevoir la sûreté de fonctionnement comme l’empilement des tranches d’emmental ; chaque tranche est un type de test de sûreté dont le niveau peut alors être calculé comme :

le rapport entre les tranches à appliquer et le niveau de risque acceptable sur une version donnée ;
le résultat des tests de ces différents contrôles identifiés le plus en amont possible comme une valeur qui sera pondérée par le poids du type de test, par exemple :

Type de test	Poids	Score du test (sur 10)	Résultat (Poids x Score)
Tests fonctionnels	10	8	80
Tests de sécurité	7	4,5	31,5
Tests d’utilisabilité	5	3	15
Tests de charges	2	9	18
Tests de migration	0 (dans notre exemple, il n’y a pas de migration de version prévue)	-	-
Tests de tolérance aux pannes	8	6	48
Tests d’exploitabilité	4	7	28
Tests de traçabilité	2	1	2
RGPD	3	5	15
SÛRETÉ		SCORE GLOBAL	5,79

Cet exemple de modélisation peut aussi inclure une pondération ou une évolution des poids suivant le contexte de la version ou toute autre valeur qui serait perçue comme pertinente dans l’évaluation de la sûreté de fonctionnement.

La difficulté avec la plupart de ces tests est qu’ils dépendent du bon fonctionnement applicatif. Dans un contexte agile, on commencera...

Tests non fonctionnels