Cet article est le premier d’une série d’articles décrivant les différents types de test définit par la norme ISO – 25 010. Vous y trouverez donc une introduction à cette norme.
Introduction :
On me pose régulièrement des questions sur les différents types de tests. Quels sont-ils ? A quoi correspondent-ils ? Comment les comprendre ? Qui les exécute ?
La notion de type de test est même parfois confondue avec les niveaux de tests.
Selon moi, la meilleure manière de parler des types de tests et de leurs caractéristiques est de se pencher sur ce qui est utilisé par le syllabus fondation ISTQB 2018, c’est-à-dire la norme ISO 25 010.
La norme ISO – 25 010 remplace la norme ISO 9126 utilisée dans le syllabus de 2011. Je l’avais d’ailleurs utilisée dans mon article sur l’adaptation de sa stratégie de test en fonction des anomalies détectées.
Concrètement, le changement le plus visible est le fait que les tests de sécurité sont maintenant considérés comme des tests à part et ne font plus parti des tests fonctionnels.
En parlant de tests fonctionnels, qu’est-ce que c’est ? S’il y a des tests fonctionnels, que représentent les tests non-fonctionnels ?
Pour rappel, les tests non fonctionnels font partie, pour 30% des professionnels du test interrogés, des grandes évolutions du test dans les 10 prochaines années.
La norme ISO – 25 010 nous propose 8 différents types de test, les voici :
Attention : je n’ai pas trouvé de traduction officielle de l’ISO – 25 010 en français. Les noms utilisés sont donc des noms que j’ai traduits. Il se peut donc qu’il y ait des imprécisions. Je remercie d’avance toute personne qui me fournirait un lien vers une version française officielle de l’ISO – 25 010.
Comme vous pouvez le constater le nombre de type de test est important. Il y a 8 familles de tests. La famille des tests fonctionnels, ceux auxquels on pense le premier et qui sont fait en premier, ne forment qu’une seule famille.
Tous les autres types de tests sont des tests « non-fonctionnels ». Il est donc facilement compréhensible que près d’1/3 des professionnels du test voient en ces tests une évolution particulièrement importante.
Chaque famille a des tests spécifiques qui lui sont liés, je vous proposerai donc des articles spécifiques pour chacun de ces familles afin de pouvoir identifier facilement (avec des exemples concrets) à quoi correspondent ces tests.
Les tests fonctionnels :
Dans cet article je n’aborderai que les tests fonctionnels.
Cette famille de test comporte, d’après la norme ISO – 25010, 3 types de tests spécifiques :
- Les tests d’exactitude
Les tests d’exactitude ont pour but de vérifier que les réponses proposées par le logiciel sont bien celles qu’il doit donner… Avec le niveau de précision attendu. Ces informations sont généralement fournies par des spécifications fonctionnelles.
Qui voudrait d’une application mail qui n’affiche pas l’ensemble des caractères dans le composeur ?
Les tests d’exactitude sont justement là pour s’assurer que cela n’arrive pas !
- Les tests de complétude
Les tests de complétude ont un autre but. Ce but est de s’assurer que le logiciel couvre bien l’ensemble, l’intégralité, des fonctionnalités et des objectifs qui sont attendus. Les fonctionnalités sont généralement renseignées dans les spécifications fonctionnelles.
Comme il est indiqué, les tests de complétude vont plus loin que simplement vérifier la présence de l’intégralité des fonctionnalités. Il est également question d’atteinte de l’ensemble des objectifs. On touche ici plus à de l’acceptation avec des besoins exprimés qui doivent être comblés. Cela dépasse donc les simples spécifications, ces dernières ayant pu « oublier » ou mal interpréter un objectif.
Qui voudrait d’une application mail qui permettent d’envoyer des mails mais pas de lire les mails reçus ?
Les tests de complétude existent pour éviter ce genre de déconvenue !
- Les tests d’aptitude à l’usage
Ces tests ont encore un autre but. Ici, il faut vérifier que le logiciel facilite vraiment l’atteinte des objectifs et des tâches qu’il doit permettre d’atteindre, d’effectuer. En effet, si l’utilisation d’un logiciel rend plus compliqué une tâche avec ce dernier que sans celui-ci, il y a très peu de chance que le logiciel soit utilisé.
Qui voudrait d’une application mail mobile qui demande 15 minutes pour envoyer un mail alors que cela prend en moyenne 5 minutes pour allumer son ordinateur, envoyer un mail puis éteindre son ordinateur ?
Les tests d’aptitudes à l’usage ont pour but de s’assurer que les fonctionnalités proposées apportent vraiment une solution viable, plus efficace que des moyens de « contournement ».
Les tests fonctionnels sont donc les tests qui permettent de savoir si le comportement de l’application est bien celui attendu. S’il répond correctement à nos demandes, s’il répond à toutes les demandes… Et s’il est intéressant d’utiliser l’outil pour répondre à nos demandes.
Ces tests permettent donc de s’assurer que le logiciel développé fait bien ce que l’on attend de lui. S’assurer de ce bon comportement est un minimum. Cela explique donc pourquoi ce sont les tests auxquels on pense en premier mais aussi pourquoi ce sont les tests qui sont le plus développés à ce jour.
Source ISO – 25 010
Syllabus ISTQB fondation 2018 Lien anglais car non disponible en français à la date d’écriture
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
La taverne du testeur 
Traduction mise à jour avec « Complétude » plutôt que « Intégralité ».
Merci à Bruno Legeard pour son retour
J’aimeJ’aime
Je me demande quelle différence précise peut-on faire entre les tests fonctionnels d’aptitude à l’usage, et les tests d’utilisabilité…
Si tu as un exemple je suis preneuse !
Merci
J’aimeAimé par 1 personne
Salut Zoé,
je pense que rien ne vaut un exemple pour illustrer la différence… Et une fois n’est pas coutume, je ne vais pas parler de mail mais d’une expérience que j’ai eue lors de la JFTL quand j’ai voulu acheté un ticket de RER entre Paris et une ville de banlieue.
Le principe est simple, pour acheter un ticket de RER depuis la banlieue à une borne il faut indiquer le nom de l’arrêt à travers un clavier électronique.
Et malheureusement, malgré cette simplicité, je me suis aperçu que je ne trouvais pas (ou très difficilement) les lettres sur leur clavier numérique… Jusqu’à ce que je me rende compte que les lettres étaient affichées ni en AZERTY ni en QWERTY mais en ordre alphabétique.
On est là typiquement dans un cas d’aptitude à l’usage (je peux écrire ce que je souhaite) mais avec une ergonomie pensée avec les pieds (à l’inverse de toute habitude et/ou instinct de n’importe quel utilisateur).
J’aimeJ’aime
Ca se tient ! Merci pour l’exemple !! 🙂
J’aimeAimé par 1 personne
[…] Les tests fonctionnels de régression […]
J’aimeJ’aime
Dans cette série d’articles, je remarque que le modèle de la qualité logicielle de l’ISO/IEC 25010 est devenu un ensemble de 8 familles de test. Pourquoi avoir remplacé, dans la traduction française proposée, les facteurs (caractéristique) et critères (sous-caractéristique) de la qualité logicielle qui doivent servir à évaluer la qualité d’un système informatique au moyen de métriques, par une typologie des tests organisée en 8 familles de test ? Peut-être s’agit-il d’une utilisation délibérée de ce modèle, mais l’article laisse penser que le diagramme n’était qu’une traduction.
Par ailleurs, en consultant le syllabus 2018 de l’ISTQB, on peut lire que les tests poursuivent des objectifs de qualité similaires à l’ISO/IEC 25010. Toutefois, la 25010 ne définit pas des types de test, mais des caractéristiques et sous-caractéristiques pour un modèle de la qualité. Et les 4 types de test identifiés par le syllabus de l’ISTQB (test fonctionnel, test non-fonctionnel, test en boîte blanche, test relatif au changement) ne sont pas les 8 caractéristiques de la qualité de la 25010, il n’y a pas de bijection possible entre les deux. Je ne suis pas non plus certain que pour chaque sous-caractéristique de l’ISO 25010, il faille ou soit pertinent de lui faire correspondre un sous-type de test. Par exemple, si on mesure le temps de réponse dans les tests de performance, peut-on dire pour autant qu’il existe un test de temps de réponse et que c’est un type de test de performance ?
Références :
– ISO/IEC 25010 : https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
– Syllabus 2018 de l’ISTQB : https://www.istqb.org/downloads/syllabi/foundation-level-syllabus.html
J’aimeAimé par 1 personne
Bonjour Xavier et merci pour ce retour.
Par rapport à la traduction avec « Famille », j’avoue que c’est la première fois que je vois les termes facteurs et critères. Lors de mes recherches je n’ai trouvé que des sources en anglais.
Pour la partie des types de test, en effet, la norme ISO-25010 ne définit pas les types de test mais les axes permettant de mesurer la qualité d’une application. Les tests étant là pour donner un indice de confiance sur la qualité il me semble cohérent de pouvoir faire un parallèle.
Enfin, pour les temps de réponse, il est possible de tester ces derniers suivant différentes conditions. Cela créé alors des tests du type Performances/temps de réponses… Mais dans ce cas il y a aussi d’autres sous-caractéristiques qui sont généralement traitées.
J’aimeJ’aime
Bonjour,
Article très intéressant pour moi qui suis « de l’autre côté de la barrière » dans le cycle de vie, au niveau de l’expression des besoins et de la spécification des exigences.
La norme ISO que vous citez est la 25000 version 2014. Elle n’a pas encore été traduite.
En revanche, la version 2005 a été traduite en français.
Entre les deux versions, la plupart des caractéristiques et sous-caractéristiques sont les mêmes.
Je vous suggère donc de jeter un coup d’œil à la 25000 version 2005 et d’utiliser la traduction officielle Afnor chaque fois que cela est possible.
J’aimeAimé par 1 personne