Duel: tests système vs tests fonctionnels

Introduction

Lorsque l’on aborde le sujet des niveaux de test on cherche des exemples pour chaque niveau. Il est possible de faire une analogie mais, dans le cas contraire, il y a souvent des raccourcis qui sont faits. Si le raccourci tests de composant/tests unitaires fonctionne généralement assez bien il y en a un autre qui fonctionne beaucoup moins bien et que j’entends régulièrement. Ce rapprochement est celui ci: les tests système c’est en fait les tests fonctionnels!

Pourquoi cette confusion ?

Je ne saurais dire exactement pourquoi cette confusion existe et est si fréquente. Je pense honnêtement que les raisons sont multiples, il y en a cependant une en particulier qui a attiré mon attention. La raison ? Un raccourci que je me suis retrouvé à utiliser en présentant les différents niveaux de test.

Les niveaux de test sont des concepts, néanmoins, les personnes avec qui l’on échange sont justement des personnes. Elles ont besoin, pour pouvoir appréhender les concepts, faire un rapprochement avec leur quotidien… Ce qui engendre une question fréquente lors de la présentation des niveaux de test: Le testeur intervient sur quels niveaux de test ?

Ma réponse est: « en général le testeur intervient sur les tests système mais il peut également intervenir à d’autres niveaux en fonction du contexte »

Cette réponse peut pousser au rapprochement: tests système = tests du testeur.

Et par simplification, effet du téléphone arabe et méconnaissance du métier de testeur (en pensant que le testeur ne fait que du test fonctionnel) on peut en arriver à cette incompréhension: Les tests système c’est les tests fonctionnel.

Quelle différences entre ces termes ?

Une fois n’est pas coutume, la différence est assez simple. J’avais d’ailleurs écrit en septembre 2019 un article comparant niveaux et types de test qui abordait ce sujet.

Les tests système

Les tests système sont un niveau de test. Ce niveau a pour but de s’assurer de vérifier que ce qui a été développé correspond à ce qui a été demandé. Attention, correspondre à ce qui a été demandé ne veut pas dire correspondre au besoin, pour cela il y a les tests d’acceptation.

Les tests système sont souvent basés sur des spécifications (particulièrement en cycle en V) ou des User Story (en Agile) (la vision cycle en V a d’ailleurs sûrement contribué à la confusion dont nous parlons car les spécifications n’abordent que trop rarement des aspects non fonctionnels pourtant fondamentaux.) mais il faut également savoir aller au delà de ces simples exigences exprimées. En effet, un grand nombre d’exigences sont induites car jugées « évidentes ».

Dans tous les cas, les tests système peuvent et doivent être amené à faire des tests fonctionnels mais ausi des tests non fonctionnels. Honnêtement, quel testeur voudrait tester une application mobile grand public sans tester sur plusieurs téléphones (adaptabilité) ? Quel testeur voudrait tester une application web grand public sans s’assurer qu’elle est capable de tenir la charge du traffic anticipé (performances) ?

On le voit bien, les tests système c’est bien plus que du fonctionnel!

Les tests fonctionnels

Les tests fonctionnels, au sens ISO-25010, c’est des tests qui ont pour but d’assurer que notre logiciel répond bien aux attentes en terme d’exactitude (fiabilité du résultat), de complétude (couverture de l’ensemble des usages) et d’aptitude à l’usage (la capacité à faire ce que l’on souhaite).

Ces tests ne sont évidemment pas bornés aux tests systèmes et font partie intégrante des tests d’acceptation. De même, cela serait une grave erreur de commencer à faire des tests fonctionnels qu’à partir du niveau test système car cela reviendrait à tester tard et aller à l’encontre du principe « Tester tôt« .

Les tests fonctionnels sont donc bien plus que du test système!

Conclusion

Tests système et tests fonctionnels sont bien différents. Les tests système vont bien au delà du fonctionnel et les tests fonctionnels doivent être sur les autres niveaux de test!

Aucun ne correspond à l’autre et aucun ne contient l’autre. Ces 2 concepts ont simplement 1 point commun qui a le malheur d’être une sorte de dénominateur commun du test et du travail du testeur pour beaucoup de personnes.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Crowdtesting

Crowdtesting (2/3): la campagne de Crowdtesting

Vue Crowdtesteur Intégrer une campagne : Pour intégrer une campagne il faut d’abord demander à y accéder. Pour savoir quelles sont les campagnes disponibles chez Stardust, le plus simple est d’être sur le Slack ce qui permet de recevoir par mail des notifications de mission décrivant les besoins: Il est également possible

Lire la suite »

Les champs dans un formulaire: un élément facile à tester ?

Les formulaires: un élément très familier Si vous êtes un internaute régulier vous avez sûrement déjà été amené à remplir un formulaire. On les voit fleurir sur un nombre très impressionnant de site web et même d’application. Si vous êtes un testeur vous êtes donc très probablement rompu à l’exercice

Lire la suite »
Qualité

Qualité vs Surqualité

Introduction :  Aussi impliqués et passionnés que nous puissions l’être dans nos métiers d’informaticiens, il ne faut pas se voiler la face, le nerf de la guerre en matière de projets reste tout de même les finances.  Pour que la réalisation d’un produit soit considérée comme un réel succès par

Lire la suite »