Les tests non fonctionnels sont-ils intégrés à votre stratégie QA ?
Une application peut respecter les règles métier et rester inutilisable. Découvrez pourquoi performance, sécurité, accessibilité et résilience doivent être intégrées à la QA.
QUALITÉ LOGICIELLE & QA
12/11/20253 min read
Une application peut réussir ses tests fonctionnels et rester problématique en production.
Elle peut calculer correctement un montant, mais mettre vingt secondes à afficher une page. Elle peut respecter le parcours prévu, mais devenir indisponible lorsque le nombre d’utilisateurs augmente. Elle peut répondre au besoin métier, mais exposer des données sensibles ou être difficilement utilisable par certaines personnes.
La qualité logicielle ne se limite donc pas à vérifier que chaque fonctionnalité produit le résultat attendu.
Que sont les tests non fonctionnels ?
Ils évaluent des caractéristiques qui influencent l’usage et la fiabilité du produit :
performance ;
sécurité ;
disponibilité ;
robustesse ;
compatibilité ;
accessibilité ;
maintenabilité ;
capacité à fonctionner sous charge ;
récupération après incident.
Ces caractéristiques doivent être définies avec suffisamment de précision pour pouvoir être testées.
Dire qu’une application doit être « rapide » ne suffit pas. Il faut déterminer dans quelles conditions et avec quel niveau de service attendu.
La performance ne se résume pas au temps de réponse moyen
Un temps moyen acceptable peut masquer des situations dégradées.
Il est utile d’observer :
le temps de réponse médian ;
les temps de réponse élevés ;
le comportement lors des pics d’activité ;
la consommation de ressources ;
les temps de traitement des opérations critiques ;
l’évolution des performances selon le volume de données.
Un parcours utilisé par quelques collaborateurs n’a pas les mêmes exigences qu’une application de vente, de paiement ou de réservation accessible à de nombreux utilisateurs.
Les tests doivent donc reproduire autant que possible les conditions réelles d’utilisation.
La sécurité doit être intégrée au cycle de test
La sécurité ne devrait pas intervenir uniquement avant une mise en production ou après un incident.
Elle doit être prise en compte dans :
les exigences ;
la conception ;
les revues de code ;
les tests d’authentification ;
les tests de droits ;
la gestion des sessions ;
la protection des données ;
la chaîne CI/CD.
L’ANSSI recommande notamment les tests de non-régression de sécurité, les analyses statiques et dynamiques ainsi que les contrôles de l’infrastructure dans les chaînes de développement et de déploiement.
Les scénarios de sécurité doivent aussi vérifier les comportements selon les profils d’utilisateurs. Une fonctionnalité accessible à un administrateur ne doit pas nécessairement l’être pour un utilisateur standard.
L’accessibilité et la compatibilité sont souvent testées trop tard
Une application peut être fonctionnelle pour l’équipe qui l’a conçue et difficile à utiliser dans d’autres conditions.
Les tests peuvent porter sur :
les navigateurs ;
les appareils ;
les tailles d’écran ;
les lecteurs d’écran ;
la navigation au clavier ;
les contrastes ;
les messages d’erreur ;
les connexions dégradées.
Ces sujets ne doivent pas être traités uniquement comme une correction esthétique. Ils peuvent conditionner l’accès au service et la capacité de certains utilisateurs à accomplir leur tâche.
La résilience doit être testée avant l’incident
Il faut également savoir comment l’application réagit lorsque quelque chose se passe mal :
service externe indisponible ;
base de données inaccessible ;
réseau interrompu ;
message reçu deux fois ;
traitement interrompu ;
fichier invalide ;
volume inhabituel ;
erreur d’authentification.
Un système robuste ne se définit pas par l’absence totale d’incident. Il se définit aussi par sa capacité à limiter les conséquences, à signaler le problème et à reprendre correctement le traitement.
Pourquoi ces tests sont-ils souvent oubliés ?
Plusieurs raisons sont fréquentes :
exigences non fonctionnelles non définies ;
responsabilité répartie entre plusieurs équipes ;
difficulté à reproduire les conditions de production ;
pression sur les délais ;
outils disponibles mais non intégrés ;
absence d’indicateurs partagés ;
perception que la QA concerne uniquement la fonctionnalité.
Pour éviter cela, les exigences non fonctionnelles doivent être intégrées au cadrage du projet, au même titre que les règles métier.
Construire une stratégie proportionnée
Toutes les applications ne nécessitent pas le même niveau de test.
La stratégie dépend notamment :
de la criticité du service ;
du volume d’utilisateurs ;
de la sensibilité des données ;
des contraintes réglementaires ;
du coût d’une indisponibilité ;
de la fréquence des évolutions ;
des dépendances externes.
Une application interne peu critique ne sera pas évaluée comme un parcours bancaire ou une plateforme de commerce. L’enjeu consiste à adapter l’effort au risque réel.
À retenir
Une stratégie QA complète doit répondre à quatre questions :
L’application fonctionne-t-elle comme prévu ?
Reste-t-elle performante dans ses conditions réelles d’utilisation ?
Protège-t-elle correctement les données et les accès ?
Réagit-elle correctement lorsque son environnement se dégrade ?
Les principes de testing rappellent qu’il est impossible de tout tester et qu’il faut concentrer les efforts sur les risques importants. Cette logique vaut également pour les tests non fonctionnels.
pragmaIT accompagne les organisations sur la stratégie QA, les tests de performance, l’automatisation, la sécurité applicative, la recette et l’industrialisation des pratiques de qualité.
Nous connectons les talents IT aux besoins des entreprises.
Vous souhaitez être contacté ?
© 2025. pragmaIT S.A.S - Tous droits réservés
Mentions légales
Nos offres