Le concept de test fonctionnel est-il particulièrement compliqué ?
D’après l’ISO-25010 cela parait assez simple et peut se résumer aux tests permettant de confirmer que l’application propose bien ce qu’on lui demande de faire!
Néanmoins malgré cette apparente simplicité, on peut s’apercevoir que le terme « test fonctionnel » a quasiment autant de définitions qu’il y a de projets ou de produits (si on travaille en agile). Je suis bien conscient que ce chiffre est exagéré mais je ne suis jamais tombé dans 2 équipes où cette définition était la même… Et cela a fréquemment provoqué des incompréhensions.
La première chose à faire lorsque l’on parle de test fonctionnel est bien de s’assurer que son interlocuteur a bien la même définition de ce concept et que nous parlons de la même chose. En effet, il n’y a rien de pire que 2 définitions différentes pour un même concept car cela engendre nécessairement des incompréhensions au sein des équipes et donc des problèmes sur les projets et produits.
D’expérience j’ai trouvé de nombreuses définitions pour les tests fonctionnels, en voici quelques-unes.
Les tests fonctionnels sont les tests définis par l’ISO-25010.
Ils couvrent les tests d’exactitude, de complétude et d’aptitude à l’usage. Ils n’ont aucun lien particulier avec les niveaux de tests et sont donc fait par les développeurs, les « métiers », les testeurs et tous les intervenants étant amenés à faire du test.
Les tests fonctionnels sont les tests faits par les testeurs!
On retrouve principalement dans cette définition une liaison avec les niveaux de test en assimilant les tests fonctionnels avec les tests systèmes.
Cette définition me dérange pour plusieurs raisons, les 2 principales étant que cela sous-entend que le fonctionnel ne peut pas se faire au niveau unitaire (pas de fonctionnel pour les développeurs) mais aussi que les testeurs ne feraient que du test fonctionnel alors qu’il est possible de faire des tests de performances, d’utilisabilité, de portabilité ou tout autre type de test. Cette définition est néanmoins assez répandue et il faut savoir s’y adapter.
Les tests fonctionnels sont les cas passants, les autres sont du « Negative testing ».
On fait face ici à une autre vision tendant à définir le fonctionnel comme les cas d’usages principaux. Or, les cas non désirés ou d’erreurs sont souvent des usages fonctionnels qu’un utilisateur détourne volontairement ou involontairement.
Les tests fonctionnels sont les tests effectués pendant l’exécution de l’application.
Ici cela revient à dire que les tests fonctionnels sont les tests dynamiques et que les tests statiques (comme les revues) ne peuvent pas proposer du test fonctionnel ce qui est un contre-sens du point de vue de la norme ISO-25010.
Prenons l’exemple d’une revue d’une User Story qui met en avant un chemin alternatif manquant. La revue est un test statique et contribue à l’enrichissement fonctionnel de l’application avec l’ajout du chemin alternatif manquant.
Les tests fonctionnels sont les tests IHM. Cette définition existe également. Elle revient un peu à celle des tests fait par les testeurs mais peut également englober le niveau des tests d’acceptation et certains types de tests comme les tests d’utilisabilité. Par définition de l’ISO-25010, les tests d’utilisabilité sont du non-fonctionnel et il serait réducteur de considérer la testabilité de l’IHM qu’à travers le prisme du fonctionnel. Cet amalgame peut s’expliquer par la proposition de Mike Cohn:
Les tests fonctionnels sont les tests de bout en bout (End to End). Cette définition est parfois présente dans les logiciels à architecture compliquée où les tests composants peuvent être des tests sur des logiciels tiers, où l’on fait appel à des systèmes embarqués ou tout simplement à de nombreux partenaires. Dans ce cas, il arrive que les tests fonctionnels soient assimilés à ces tests.
Les tests fonctionnels sont les tests manuels. Cette définition est plus rare mais je l’ai déjà rencontrée. L’équipe en question faisant la différence entre les tests automatisés appelés tests automatisés et les test manuels qui devenaient les tests fonctionnels. J’avoue que cette définition me dérange car on a ici, selon moi, une confusion entre type de test et la manière de les exécuter.
Les tests fonctionnels sont les tests de (non) régression. Il y a d’ailleurs un article dans la taverne visant à bien expliquer la différence entre ces 2 points.
Au final, qui a raison ?
Je serai bien tenté de dire que c’est l’ISO-25010 qui a raison car c’est la définition que j’utilise.
Néanmoins il n’y a en vérité aucune bonne ou mauvaise définition. L’important quand on fait du test, c’est de bien se faire comprendre lorsque l’on communique. Il faut donc se mettre d’accord sur le vocabulaire utilisé dans nos équipes respectives. Suivre les définitions de l’ISTQB ou des normes peuvent aider mais ce n’est pas une fin en soi, ni l’essence même du test.
L’important est d’avoir une stratégie efficace, de faire les tests qu’il faut pour atteindre le niveau de qualité souhaité lo.
Pour cela la dénomination importe peu tant que le but est atteint.
Néanmoins, j’affectionne particulièrement la définition de l’ISO-25010 promue par l’ISTQB car les certifications ISTQB, détenues par plus de 100 000 testeurs à travers le monde, proposent un vocabulaire commun à toutes ces personnes. Ce qui nous permet de mieux se comprendre et d’éviter un certain nombre d’incompréhensions.
Image principale trouvée sur https://www.futura-sciences.com/sciences/actualites/vie-site-meilleur-actu-dessins-humoristiques-s47-17450/
https://martinfowler.com/articles/practical-test-pyramid.html
Article écrit à 4 mains par Marc Hage Chahine et Benjamin Butel.
N’hésitez pas à nous suivre et lire nos autres articles (Marc, Benjamin) si vous voulez en apprendre plus sur le test ou venir partager vos connaissances.
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 nos articles.
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
La taverne du testeur 
Je trouve très intéressant de passer en revue toutes les interprétations rencontrées ici et là. Cela contribue grandement à l’intérêt de l’article.
Partager un vocabulaire commun et exact est plus important qu’il n’y paraît : c’est l’emploi d’un même vocabulaire qui permet à plusieurs acteurs de se coordonner, et donc de mettre en œuvre une stratégie de test. Quand l’ensemble des tests incombe à une seule personne qui travaille de façon isolée, c’est sans doute le seul cas où l’on peut faire l’ économie d’un vocabulaire rigoureux, et encore… Je pars du principe qu’un vocabulaire rigoureux permet de structurer la pensée et d’être plus efficace.
À chaque fois qu’il est question de l’ISO-25010, pourriez-vous citer précisément la norme ?
J’aimeAimé par 1 personne
Bonjour Xavier,
merci pour ce retour.
En effet, la grande majorité des échecs ou des erreurs que j’ai rencontrées étaient liées à la communication. Cette communication est souvent affaiblie par un vocabulaire qui n’est pas commun.
Proposer un vocabulaire commun est d’ailleurs , pour moi, la principale force de la certification ISTQB fondation.
Pour la question de l’IOS-25010 je vais faire plus attention afin de bien la citer à chaque fois
J’aimeJ’aime
Merci Xavier pour ton retour.
Je suis en phase sur l’intérêt de partager un vocabulaire commun mais la notion d’exactitude est de suite très relative.
Bien-sur il y a la norme ISO-25010, largement reprise par l’ISTQB, mais en pratique, ça reste peu connu surtout par des équipes de développement.
A mon sens, il est préférable, au sein d’une équipe, de parler le même vocabulaire, de bien le définir collectivement afin de parler de la même chose. Mais si au final, le choix collectif abouti à un vocabulaire pas complètement en phase avec la norme, cela ne me dérange pas dès lors que cela ne nuit pas à la qualité de ce qui est produit.
J’utilise souvent les rétrospectives pour essayer de corriger les défauts de vocabulaires mais je pense qu’il faut aussi être pragmatique et pas tout le temps dogmatique.
Cela n’engage que moi bien-sur 🙂
J’aimeJ’aime
[…] La « stratégie » de test est un terme très utilisé et qui est devenu générique. Vous pourrez d’ailleurs lire prochainement un article dédié aux mécompréhensions sur ce terme sous la forme de l’article sur les tests fonctionnels. […]
J’aimeJ’aime