Assurance qualité : de l'importance des tests fonctionnels
Le test dans un projet IT
Depuis une vingtaine d’années, le monde se « numérise » à marche forcée (énergie, télécommunication, transports, défense, sécurité…) et derrière tous nos gestes élémentaires du quotidien se cachent des dizaines de milliers de lignes de code d’applicatifs qu’il faut concevoir, développer, entretenir et bien sûr valider (par du test). Les tests sont une activité substantielle de l’ingénierie des systèmes qui va structurer le futur de nos sociétés hyper connectées, et des prévisions prévoient 50 milliards d’objets connectés via Internet aux alentours de 2030 soit l’équivalent de 6 par être humain.
Dans l’IT, le but d’un projet est de répondre au besoin d’un client ou de futurs utilisateurs en couvrant les exigences d’un cahier des charges. Ce dernier contient des fonctionnalités à partir desquelles les spécifications fonctionnelles de l’applicatif ou du site internet à réaliser seront décrites.
Dans ce contexte, les tests permettent de garantir un niveau de qualité de ce qui sera produit par l’équipe en charge d’un projet. Cette notion de qualité est certes subjective et n’aura pas la même signification selon que l’on soit développeur, responsable du SI concerné, utilisateur ou financier. Par exemple :
- Le développeur souhaitera voir la qualité du code produit : est-il modulaire, générique, compréhensible, documenté, facile à maintenir…
- Le responsable du Système d’Information s’attachera à savoir si le logiciel sera facile à administrer et qu’il ne sera pas susceptible de corrompre la sécurité globale du SI.
- L’utilisateur final attendra lui, plutôt qu’un logiciel corresponde à son besoin, en étant si possible ergonomique voire esthétique.
- Le financier voudra s’assurer que le logiciel se vendra bien, qu’il permette de faire du profit ou s’il permet d’améliorer la compétitivité de la structure.
La création logicielle est une activité humaine, donc par nature soumise à erreur. Elle passe par plusieurs étapes et le test en est une au même titre que le développement.
Qu’est-ce que le test fonctionnel ?
La norme ISO/IEC 25010 définit 8 grandes familles de tests (fonctionnels, de performance, de compatibilité, d’utilisabilité, de fiabilité, de sécurité, de maintenabilité et de portabilité). Il existe également 4 niveaux de tests selon l’ISTQB® [1] (tests de composants, tests d’intégration, tests système, tests d’acceptation) couverts par les 8 familles de tests susmentionnés.
Mais alors qu’entend-on exactement par « tests fonctionnels » ?
Les tests fonctionnels étant bien nommés, les 7 autres types de tests sont, par opposition, dits « non-fonctionnels ». Les tests fonctionnels ont ainsi pour but de démontrer que l’application ou le site que l’on teste, effectue ce pour quoi il est fait en recherchant d’éventuelles défaillances lorsqu’on le sollicite sur des valeurs nominales.
Plus simplement, les tests fonctionnels visent à qualifier ce qu’un logiciel fait alors que les tests non-fonctionnels, eux, visent à qualifier la façon dont il le fait.
Toujours selon la norme ISO/IEC 25010, les tests fonctionnels sont composés de ce qu’on pourrait traduire par tests d’exactitude (Fonctional Correctness), de complétude (Fonctional Completeness) et d’aptitude à l’usage (Fonctional Appropriateness).
- Les tests d’exactitude : sont le degré avec lequel un ensemble de fonctions couvrent toutes les spécifications et demandes utilisateurs.
- Les tests de complétude : sont le degré avec lequel un produit ou un système renvoit des résultats corrects pour un degré de précision attendu.
- Les tests d’aptitude à l’usage : sont le degré avec lequel les fonctions facilitent l’exécution de tâches et d’objectifs spécifiés.
Il n’existe pas de définition officielle des tests fonctionnels, et il conviendra, en amont d’un projet, de s’assurer que toutes les parties prenantes parlent de la même chose à ce sujet. Ce qui est évident pour les uns ne l’est pas forcément pour les autres et le but final restant de livrer un produit de qualité.
L’intérêt de tester et les risques à ne pas tester
Souvent mal perçus, les tests fonctionnels sont indispensables pour vérifier la conformité des fonctionnalités d’un applicatif avant sa livraison. La qualité de celui-ci s’en trouve alors améliorée notamment dans son utilisation réelle.
Les tests fonctionnels vont également fournir des informations sur le niveau de qualité du produit livré. Ces informations en permettront un suivi lors de ses évolutions.
Sans l’assurance qualité, il est compliqué d’évaluer la fonctionnalité d’un produit et surtout il devient extrêmement difficile de repérer des défauts critiques qui deviennent coûteux à traiter a posteriori. Il est également difficile de satisfaire et garantir non seulement les exigences des clients, mais aussi les objectifs et les attentes de l’entreprise qui produit l’applicatif.
Faire l’impasse sur les tests fonctionnels comporte des risques en termes de coûts, de maintenabilité, et parfois même humains (systèmes d’assistance à la conduite de véhicules par exemple…). Malgré cela, on peut constater encore trop souvent, qu’ils se retrouvent écartés des processus par manque de temps, de budget, ou même par méconnaissance. Et les anomalies non détectées faute de test seront embarquées dans les évolutions successives du logiciel pouvant entraîner des conséquences à plus ou moins long terme. C’est pourquoi intégrer tôt le test au cœur du cycle de vie des applicatifs permettra de gagner du temps en traquant les anomalies le plus tôt possible.
Négliger les activités de test, pour livrer plus vite de nouvelles fonctionnalités ou de nouveaux produits, pourrait être tentant. Or, les erreurs sont consubstantielles à l’acte de programmation, aussi, il faut surtout s’organiser en conséquence en faisant de l’activité de test un impératif. Le préventif sera toujours moins coûteux que le curatif et ne pas intégrer la validation dans un projet logiciel se fera au détriment de la satisfaction clients.
[1] L’ISTQB® (en anglais « International Software Testing Qualifications Board ») est le Comité international de qualification du test logiciel.