Tests non fonctionnels : qu'est-ce qui définit si le système est bon en plus de fonctionner

Un système peut réussir tous les tests fonctionnels et néanmoins être un échec.

Il fait exactement ce que demande la spécification. Chaque bouton fonctionne, chaque calcul est correct, chaque flux se complète. Et même ainsi, il est lent au point d'irriter, il plante lorsque beaucoup de gens l'utilisent, il fuit des données dès la première tentative d'attaque et il est tellement enchevêtré que personne ne peut le modifier sans casser trois autres choses. Ça marche, et c'est mauvais.

Cette différence entre « fait ce qu'il est censé faire » et « le fait assez bien pour être réellement utilisé » est exactement le territoire des tests non fonctionnels. Ils constituent, à mon avis, l’élément de qualité qui distingue le plus les produits professionnels des prototypes déguisés.

Fonctionnel versus non fonctionnel

La distinction est simple à énoncer et profonde dans ses conséquences.

Les tests fonctionnels vérifient ce que fait le système : étant donné une entrée, produit-il la sortie correcte ? L'inscription enregistre-t-elle ? Le paiement est-il traité ? Le rapport fournit-il les bons chiffres ? Ce sont des questions sur le comportement et la correction.

Les tests non fonctionnels vérifient le fonctionnement du système : sa rapidité, sa sécurité, sa fiabilité, son évolutivité, sa facilité d'utilisation et de maintenance. Ils ne demandent pas « est-ce que ça marche ? », mais plutôt « est-ce que ça marche bien ? ». Vitesse, sécurité, stabilité sous charge, accessibilité, tout cela n'est pas fonctionnel.

Le piège est que les fonctionnalités sont faciles à spécifier et à facturer, elles attirent donc presque toute l'attention. Le non-fonctionnel est diffus, facile à reporter et est donc généralement négligé, jusqu'à ce qu'il devienne la raison pour laquelle le système échoue en production.

Les dimensions qui comptent

"Non fonctionnel" est un grand parapluie. Il est utile d’en connaître les principales dimensions, car chacune d’entre elles représente une manière différente pour le système de décevoir, même lorsqu’il fonctionne.

Les performances sont les plus visibles : temps de réponse, vitesse d'utilisation. Un système correct mais lent perd silencieusement des utilisateurs. L'évolutivité et la capacité dépendent de sa capacité à gérer la croissance et les pics de demande, plutôt que de fonctionner uniquement lorsque peu de personnes l'utilisent.

La fiabilité et la disponibilité sont une question de continuité : le système résiste-t-il au fil du temps, se remet-il des pannes et ne corrompt-il pas les données ? La sécurité vérifie s'il résiste à une utilisation malveillante, et c'est là que réside la catégorie de défauts la plus coûteuse, car une faille de sécurité ne frustre pas l'utilisateur, elle l'expose.

La convivialité et l'accessibilité demandent si de vraies personnes, avec des capacités et des contextes différents, peuvent réellement l'utiliser. Et la maintenabilité, la plus invisible de toutes, demande si l'équipe peut faire évoluer le système sans que chaque changement ne devienne un champ de mines.

Pourquoi les non-fonctionnels sont différés (et pourquoi c'est un bug)

Il y a une raison structurelle pour laquelle le non-fonctionnel est négligé : il n'apparaît pas dans la démonstration.

Lorsque vous montrez le système à un client ou à un responsable, vous montrez des fonctionnalités. "Ecoute, fais ceci, fais cela." Personne ne démontre « regardez comme il peut résister à dix mille utilisateurs » ou « regardez comme il résiste à une attaque ». Ces qualités sont invisibles jusqu’au jour où elles disparaissent, puis elles apparaissent comme une crise.

Le résultat est une fausse économie. Les tests de chargement, de sécurité et d'accessibilité sont reportés car "il faut d'abord que ça marche". Ensuite, le système entre en production, plante au premier pic, perd des données ou exclut une partie des utilisateurs, et le coût d'une correction tardive est plusieurs fois plus élevé que ce qu'il aurait été pour un test à temps.

Dans le secteur public, cela est particulièrement grave. Un système de services aux citoyens qui fonctionne mais qui est lent, peu sûr ou inaccessible ne sert pas ceux qui en ont le plus besoin. Et lorsqu'il s'agit de données personnelles, la faille de sécurité non fonctionnelle se heurte directement à la LGPD, elle cesse d'être un problème technique et devient un problème juridique.

Tester le non fonctionnel nécessite un état d'esprit différent

La fonctionnalité de test est relativement simple : définir les entrées, vérifier les sorties. Tester ce qui n'est pas fonctionnel est plus difficile car cela nécessite de définir ce qui est « assez bon », et c'est une décision et non un fait.

À quelle vitesse est-il assez rapide ? Combien d'utilisateurs simultanés peut-il « gérer » ? Quel niveau de disponibilité est acceptable ? Ces questions n’ont pas de réponse universelle ; dépendent du contexte de l’entreprise et des utilisateurs. La première tâche des tests non fonctionnels est donc de transformer des qualités vagues en objectifs mesurables. « Rapide » n'est pas testé ; "répondre en dessous de ce délai dans 95% des cas" est testé.

La conséquence pratique est que les exigences non fonctionnelles doivent être définies très tôt, en même temps que les exigences fonctionnelles. Les traiter après coup, c’est garantir qu’ils seront testés trop tard, voire jamais.

Les erreurs qui rendent l'effort inutile

La première erreur est de ne pas se fixer d’objectifs. Sans objectif, « tester les performances » revient à collecter des chiffres sans savoir s'ils sont bons ou mauvais. Le but doit venir avant le test.

La seconde consiste à tester dans un environnement irréaliste. Mesurer les performances sur une machine autre que la production, ou la sécurité sans scénarios d'attaque réalistes, génère des résultats trompeurs. Le non fonctionnel est particulièrement sensible à l'environnement, les chiffres ne sont valables que si les conditions ressemblent à la réalité.

La troisième consiste à le traiter comme un événement unique. Les performances, la sécurité et la fiabilité se dégradent avec le temps, à chaque modification apportée au système. Un test de sécurité effectué une seule fois au lancement en dit peu sur la sécurité six mois et cinquante versions plus tard. Le non fonctionnel a besoin de récidive.

La qualité est ce qui reste lorsque la fonctionnalité est considérée comme acquise

Il y a un moment dans la maturité d'un produit, et d'une organisation, où « ça marche » cesse d'être une réalisation et devient un point de départ. Dès lors, la vraie qualité se définit par le non fonctionnel : c'est rapide, c'est sûr, ça tient, ça tient, c'est accessible, c'est possible d'évoluer.

Les équipes de startup célèbrent « ça marche ». Les équipes matures savent que ce n’est que le sol. Ce qui distingue un système professionnel d'un système amateur, c'est rarement ce qu'il fait, c'est la façon dont il le fait, sous pression, dans la durée, pour tout le monde. Ce « dans quelle mesure » est précisément ce que protègent les tests non fonctionnels.

Les ignorer n’épargne pas d’efforts. Cela transfère simplement le coût au pire moment possible : la production, en présence de l’utilisateur.

Si votre produit « fonctionne » mais que vous n'avez jamais mesuré sa rapidité, sa sécurité ou sa résilience, il existe probablement un risque non fonctionnel qui attend d'apparaître. J'ai d'autres articles sur le blog sur les performances, la sécurité, la fiabilité et la qualité des logiciels qui abordent chacune de ces dimensions.