Plan de validation : vérifiez que votre produit répond aux besoins client21 min read

J'adore quand un plan de validation se déroule sans accroc

Nous allons voir comment construire un plan de validation qui vous assurera que le produit que vous vous apprêtez à livrer répond aux besoins de votre client.


Point sur le vocabulaire

Avant d’aller plus loin, voici les définitions de quelques termes utilisés dans cet article.

UST
Signifiant Unité Sous Test, c’est le nom générique qu’on donne au produit sur lequel on va effectuer les tests. On trouve aussi la notation UUT (Unit Under Test).


A quoi ça sert ?

Plus vous créez des produits complexes, plus il est difficile de s’assurer de manière exhaustive que ces produits répondent précisément au besoin initial. On l’a vu dans un précédent article sur les matrices de traçabilité, les liens tissés entre le besoin qu’un client exprime et la solution que vous lui présentez peuvent être très nombreux ! Or ce sont précisément tous ces liens qu’il faut valider pour être sûr que le produit est complet.

De plus, il n’est pas rare qu’en cours de route, une évolution vienne remettre en question ce qui a été fait : “il faut que la voiture possède 7 places et non plus 5”. “Ah donc il faut allonger le châssis, mettre un moteur plus puissant…”. Ces évolutions ne doivent pas altérer ce qui fonctionnait déjà. Il faut pouvoir s’en assurer, c’est ce qu’on appelle des tests de “non-régression” : lorsqu’on vérifie qu’une fonctionnalité A n’est pas incompatible avec une fonctionnalité B. Ce qui marchait doit toujours marcher.

D’où l’intérêt de construire une liste de tests qui permettent de vérifier que tout fonctionne ensemble : un plan de validation !

A quoi ça ressemble ?

Suivant la complexité du projet, la description des tests du produit peut prendre plusieurs formes. De la plus légère à la plus robuste, nous en avons identifié 3 :

1. Dans le même document que la définition de la solution

Les spécifications et les tests sont dans un même document
Les spécifications et les tests sont dans un même document

Votre client vous a exprimé son besoin dans un cahier des charges. Vous y répondez dans un document de spécification. Celui-ci contient contient les descriptions des fonctionnalités de votre futur produit et chacune est suivie du test correspondant. Celui-ci contient un statut (une case à cocher) pour signifier que le test est OK ou non.

L’avantage est que vous limitez le nombre de documents en réunissant tout dans un seul.

L’inconvénient est que si le projet grossit, il se peut qu’un même test serve pour deux solutions or avec ce format il n’est pas possible de “factoriser” les tests et il peut y avoir redondance. Ce qui n’est pas optimal.

2. Dans un document de test séparé

Les tests (procédures et résultats) sont dans un document séparé
Les tests (procédures et résultats) sont dans un document séparé

Votre client vous a exprimé son besoin dans un cahier des charges. Vous y répondez dans un document de spécification. Et vous décrivez les tests sur les fonctionnalités dans un document à part. Et chacun des tests peut avoir des champs à compléter pour préciser ses résultats (les valeurs des mesures, des statuts de passage, des commentaires…).

L’avantage est que vous pouvez maintenant factoriser les tests : vous décrivez une procédure qui va vérifier le bon fonctionnement de plusieurs fonctionnalités à la fois. Ceci fait gagner un temps considérable !

Le premier inconvénient c’est qu’il va vous falloir suivre les liens entre les descriptions de fonctionnalités et les tests pour savoir qui teste quoi et inversement. Mais cela se fait facilement avec une matrice de traçabilité !
Le second est que de tels tests pour être efficaces doivent avoir une procédure détaillée. Or si vous cumuler dans un même document procédure et résultats des tests, vous aller atteindre un nombre de pages important.
De plus si vous devez livrer 2 produits identiques, il faut dérouler les tests sur les 2 produits. Vous allez donc fournir 2 documents volumineux dont la moitié du contenu sera identique ! Mieux vaut ne pas avoir à les imprimer.

3. Dans 2 documents séparés : procédures et rapports de tests

Les tests sont dans 2 types de documents : un pour les procédures et un pour les résultats
Les tests sont dans 2 types de documents : un pour les procédures et un pour les résultats

Voici la forme que nous trouvons la plus optimale :

  • Les procédures de tests sont détaillées dans un premier document.
  • Le rapport de tests contient les résultats issus des procédures de tests propres à un produit.

L’inconvénient immédiat qu’on constate est la multiplication des documents ! On passe de 2 à 4 voire plus si on livre plusieurs produits ! Ceci entraîne la gestion de matrices de traçabilité supplémentaires, une pour chaque lien rouge.

Mais nous trouvons cette façon de faire optimale pour plusieurs raisons :

  1. Chaque document traite d’un seul aspect du projet : les spécifications traitent de votre solution, les procédures de tests traitent de comment valider chacune de vos spécifications et enfin les rapports de tests traitent de comment chacun de vos produits se comporte face à ces tests.
  2. Les documents sont plus courts et donc plus facilement maintenables.
  3. Les documents peuvent évoluer chacun indépendamment les uns des autres.

Dans la suite de l’article, nous allons détailler la structuration des procédures et des rapports de tests. Nous les traiterons comme 2 documents distincts mais l’organisation présentée sera la même s’ils sont fusionnés en un seul.

Les procédures de tests

C’est dans ce document que vous aller définir les procédures de tous les tests nécessaires pour assurer que le produit que vous allez livrer répond bien à tous les besoins du clients.

Il faut qu’à la fin du document, il y ait suffisamment de test pour que toutes les spécifications de votre produit soient validées par au moins un test. Pour autant, cela ne signifie pas qu’il faille un test par spécification. Nouvel avantage d’un tel document, vous pouvez faire :

  • un test pour une spécification ;
  • un test pour plusieurs spécifications en même temps ;
  • plusieurs tests pour vérifier une seule spécification si elle est très complexe.

C’est là que les matrices de traçabilité interviennent. Elles permettent de s’assurer qu’il y a au moins un test qui couvre chacune des spécifications. Si ce n’est pas le cas, il faut écrire davantage de procédures pour tester toutes les éventualités.

Comment structurer une procédure de test ?

Une procédure de test se découpe en 2 éléments :

  • la carte d’identité du test ;
  • les étapes du test.

La carte d’identité

Cette carte d’identité réunit plusieurs informations qui n’ont rien à voir avec le déroulement du test. Nous allons vous présenter celles qui nous semblent nécessaires même si toutes ne sont pas indispensables.

Une référence unique

Cette référence permet d’identifier de manière unique et immédiate le test. Elle sera très utile dans la matrice de traçabilité. Elle peut éventuellement être accompagnée d’un numéro de version pour suivre les évolutions du test.

Un titre

Essentiel pour avoir une idée rapide de ce que fait le test et pouvoir le resituer rapidement lors d’une discussion avec des collègues par exemple.

Une description

Vous résumez ici succinctement ce que fait le test et quel est son but. Cela donnera une idée à la personne qui déroulera le test, de ce à quoi elle doit s’attendre.

Les conditions initiales

Cet élément est indispensable ! Il est le garant de la répétabilité du test.

De plus, certains tests peuvent être si longs qu’il est préférable de les découper en plusieurs procédures. Ou alors plusieurs tests peuvent débuter de la même manière. Vous aurez alors envie de les découper en 2. Un test “tronc commun” puis des tests “spécifiques”. Ceci sous-entend que pour dérouler un test “spécifique”, il faut avoir déroulé le test “tronc commun” au préalable.

Voilà à quoi servent les conditions initiales. Elles vous permettent de préciser quels sont les tests, ou les mises en configuration, qu’il faut avoir effectués avant de dérouler le test présent. Elles vous permettent de séquencer vos procédures.

La traçabilité

C’est ici que vous listez toutes les références des spécifications du produit, que vous allez tester dans cette procédure.

Ainsi la compilation des traçabilités de toutes les procédures permettra de savoir si les tests couvrent l’intégralité des spécifications de votre produit.

Les autres attributs possibles

Voici quelques autres attributs que vous pouvez ajouter à cette carte d’identité :

  • Le type de test : cela permet de classifier vos procédures. Il y a par exemple des tests d’inspection qui demandent de constater visuellement la présence d’un élément, sans interaction avec le produit. Les tests de certification demandent de vérifier l’existence d’un certificat attestant le bon fonctionnement d’un composant de votre produit issu du commerce. Les tests de démonstration qui requièrent de manipuler le produit pour obtenir des résultats particuliers.
  • Une notion de gravité du test : certains tests peuvent être plus importants que d’autres. Vous pouvez vouloir faire des tests qui, s’ils ne sont pas “Ok”, n’impactent pas pour autant la validité du produit. En les classant suivant des niveaux de gravité différents, vous pourrez prioriser les tests importants.

Les étapes du test

C’est ici que nous allons réellement décrire ce qui se passe dans le test, étape par étape. Chacune d’entre elle prend simplement la forme d’une ligne dans un tableau. Je vous recommande chaleureusement de séquencer votre test de manière explicite afin qu’il n’y ai aucun doute possible dans le déroulé des étapes. Un excellent test est un test qui pourrait être exécuté par une personne qui n’a aucune connaissance de votre produit ou même du projet.

Un chien fait des expériences scientifiques

Ce principe d’exhaustivité possède plusieurs avantages:

  1. En ayant une procédure détaillée, lors du déroulement du test vous vous focalisez sur celui-ci et vous ne vous posez pas de question sur le pourquoi de chaque étape.
  2. Vous pouvez faire réaliser le test par une personne qui n’y connaît rien, et donc qui ne sera pas biaisée par sa connaissance du projet. Un tel individu sera mieux disposé à mettre en évidence des failles du test ou du produit (Cf. Comment faire un bon rapport d’erreur). Nous reviendrons sur ce point très important en fin d’article.

Nous allons maintenant passer en revue les différentes colonnes devant figurer dans votre tableau des étapes du test.

Un numéro d’étape

Ce numéro permettra d’identifier l’étape dans un éventuel rapport d’erreur, un échange avec un collègue ou même dans une autre étape du même test.

La description de l’étape

Une étape peut se définir de 2 manières :

  • soit c’est une action à réaliser qui n’attend pas de résultat décisif pour l’objet du test ;
  • soit c’est une action à réaliser qui attend un résultat particulier et dont la manifestation décidera d’un statut de l’étape, voire du test entier.

C’est ici qu’il vous faut être le plus explicite possible dans votre description de l’action à réaliser. Il ne faut pas laisser de place à une interprétation différente, à dire des évidences ou enfoncer des portes ouvertes, à prendre de la place dans la case du tableau.

Le résultat attendu

Cet élément n’est pas à compléter pour une action qui n’attend pas de résultat. Mais lorsque c’est le cas, détaillez précisément ce qui est attendu pour que le test soit Ok :

  • si c’est un comportement, encore une fois sa description ne doit pas laisser de doute possible. Il ne faudrait pas que l’opérateur considère nul un test qui serait en réalité passant. Et inversement.
  • si on attend une mesure, préciser sa valeur, son unité et un intervalle de valeurs acceptables. Exemple : la hauteur d’un élément doit être de 2 mètres, plus ou moins 1 centimètre. Si la hauteur est de 2,005 m, le test est “Ok”.
D’autres attributs possibles

Voici quelques autres attributs que vous pouvez ajouter au tableau des étapes

  • Traçabilité : pour chaque étape vous pouvez repréciser la référence de la spécification qu’elle teste. C’est surtout valable pour les actions qui attendent un résultat. Cela permet d’identifier facilement la partie critique du test. Mais cela peut être redondant avec la carte d’identité de la procédure.
  • Gestions des tests non passants : il est implicitement accepté que si une étape est “Ok”, alors on passe à la suivante. Mais que faire si l’étape n’est pas “Ok” ? Soit vous précisez pour chaque étape ce qu’il faut faire dans une colonne dédiée. C’est un peu lourd comme procédé. Soit vous définissez une procédure particulière à mettre en œuvre en cas d’échec du test. Par exemple, pour un appareil électrique, cette procédure consisterait à l’éteindre correctement. Vous pouvez, par exemple, présenter cette procédure en début de document et y faire référence là où on en aurait besoin.

Voilà pour ce qui est de la structuration des procédures de test. A la fin du document qui les réunie toutes, pensez à présenter des matrices de traçabilité pour établir le maillage avec vos spécifications de produit.

Passons maintenant au rapport de test.

Les rapports de tests

Ce sont un peu les “petits frères” des procédures de test. C’est dans ces rapports que pour chaque procédure et chacune de leurs étapes on consigne les résultats observés. On constate donc que pour une seule procédure, il doit y avoir un seul rapport de test par produit. Ici, la relation avec le produit doit être en 1 pour 1.

On a vu qu’un des intérêts de séparer les résultats des procédures dans 2 documents était la possibilité de dérouler les tests sur plusieurs produits. Ainsi chaque document de rapports de tests ne concerne qu’un seul produit à la fois. Donc la première chose à faire est d’identifier le produit testé.

Identification de l’unité sous test

“Unité sous test” est le nom générique que l’on donne au produit qui passe le test. Par la suite, je m’y référerai en l’appelant l’UST.

En début de document, dans un paragraphe dédié, on va très précisément identifier cet UST. Le but est de pouvoir le distinguer d’un autre produit identique. Par exemple, tous les iPhones passent des tests avant d’être commercialisés. Or il faut bien pouvoir rattacher son rapport de test à un iPhone et ne pas le confondre avec celui d’un autre iPhone. On peut donc utiliser son numéro de série.

Même si ceux-ci peuvent varier d’un type de produit à un autre, on retrouve généralement les attributs suivants dans l’identification d’un UST :

  • Le nom du modèle et son numéro de version ;
  • Le numéro de série ;
  • La date de fabrication.

Il faut aussi définir un statut global du test de cet UST, basé sur la compilation de tous les statuts de chacun des rapports de tests. Celui-ci sera bien évidemment à remplir une fois que tous les tests auront été effectués. Il permettra de dire en un seul mot si le produit répond ou non au cahier des charges. Et pour plus de détails on pourra aller consulter les rapports de tests qui ont échoué afin de comprendre pourquoi.

Comment structurer des rapports de test ?

L’UST est identifié de manière unique, on peut donc passer aux rapports de test. Tout comme les procédures, ceux-ci se divisent en 2 éléments avec de légères variations :

  • La carte d’identité du rapport ;
  • Les résultats étapes par étapes.

La carte d’identité du rapport

La référence

On rappelle la référence de la procédure à laquelle correspond ce rapport. Cela pourrait être une référence propre au rapport, mais elle impliquerait alors une nouvelle matrice de traçabilité pour faire le lien entre la procédure et les rapports. Cette matrice ferait du point à point. Elle n’aurait pas grande valeur ajoutée.

Le titre

On rappelle le titre de la procédure pour simplifier l’identification du rapport. Nous sommes humains, les numéros et les références ne nous parlent pas beaucoup…

La date

On renseigne la date à laquelle est effectuée le test. Cette information peut être utile en cas de problème. Elle permettra de recouper des informations issue d’autres sources comme par exemple des fichiers de rapports automatiques de logiciels.

Identification de l’opérateur de test

Lorsque plusieurs personnes sont amenées à dérouler des tests ou lorsque celles-ci sont différentes de celles qui ont développé l’UST, il est utile de pourvoir les identifier.

En cas de test non passant, la personne en charge de résoudre le problème peut avoir besoin de davantage d’informations sur ce qui a mené à l’erreur et donc interroger l’opérateur de test (Cf. Comment faire un bon rapport d’erreur).

Le statut du test

C’est l’information la plus importante d’un rapport de test. Il est la compilation des statuts de chacune des étapes. À son tour il permet de dire en un seul mot si l’UST a validé la procédure de test ou non. Et si ce n’est pas le cas, on pourra aller consulter le commentaire global ou les étapes incriminées dans l’échec du test.

En général, pour que le statut d’un test soit “Ok” ou “Réussi”, il faut que toutes les étapes aient été passées avec succès.
A l’inverse, pour que le test échoue, il suffit qu’une seule étape ne soit pas “Ok” ou “Réussie”.

Attention, un test qui échoue n’est pas forcément synonyme d’UST non fonctionnel. En début de campagne par exemple, cela veut peut-être dire que le test est à revoir.

Commentaire global

Cela permet à l’opérateur d’apporter des précisions sur le déroulé du test. Il peut y mettre ses observations et donner des précisions en cas d’échec.

Les attributs qu’on ne répète pas

Puisque la relation entre le rapport et la procédure est en 1 pour 1, il n’y a pas besoin de répéter la description du test, sa traçabilité ou ses conditions initiales. Ils ne feraient qu’alourdir le document et pourraient compliquer sa mise-à-jour. Si besoin, on va consulter la procédure correspondante, mais le test se déroule généralement avec les deux document sous les yeux.

Les résultats étapes par étapes

Numéro d’étape

On retrouve le numéro de l’étape pour faire le lien entre la procédure et le résultat. Cela évite d’avoir à répéter la description.

Mesure

Cette colonne permet de saisir la mesure effectuée lorsque l’action en requiert une. Elle n’est donc pas forcément remplie.

Statut

Vous pouvez attribuer un statut à chaque étape pour signifier qu’elle a été passée avec succès ou non :

  • “Done” / “Fait” / “Ok” : pour une étape qui n’attend pas de résultat particulier, simplement pour signifier qu’elle a été réalisée. Ici une case à cocher ferait l’affaire.
  • “Ok” / “Réussi” / “Passant” : l’action qui nécessitait un résultat a été effectuée et le résultat en question correspondait à l’attendu.
  • “NOK” (pour non Ok) / “Echec” / “Non-Passant” : l’action qui nécessitait un résultat a été effectuée mais le résultat ne correspondait pas à l’attendu.
Commentaire

On peut avoir un espace de commentaire pour chaque étape. Celui-ci sera très utile pour apporter des précisions en cas d’échec de l’étape.

D’autres attributs possibles

Action externe : lorsqu’une étape est mise en échec, peut-être est-ce dû à un problème à résoudre sur l’UST, il va falloir mener une investigation pour comprendre en créant un rapport d’erreur par exemple. Ou alors peut-être faut-il reprendre la procédure de test qui n’est pas bonne, il va alors falloir rédiger une fiche de relecture. Ce champ “action externe” permet d’indiquer la référence de ce plan d’action et donc de définir la stratégie à mettre en œuvre pour résoudre le problème.

Ceci conclue la manière de structurer le plan de validation pour tester votre produit. Mais avant de terminer, je voudrais attirer votre attention sur une notion pour atteindre une qualité optimale…

De l’importance que le concepteur, le développeur et le testeur soient 3 personnes différentes.

C’est une démarche qui peut sembler coûteuse à priori mais qui, si vous devez industrialiser vos tests à grande échelle, vous permet d’éviter de biaiser vos campagnes de tests et donc d’augmenter la qualité de vos produits.

Tout d’abord, j’entends par “concepteur”, la personne qui a conçu les spécifications du produit, qui en a fait les plans, qui a réfléchi à ses fonctionnalités, qui en a rédigé les tests. (On pourrait même être encore plus tatillon ici. Mais je vais m’abstenir pour le moment.)

Par “développeur”, je veux parler de la personne qui a littéralement construit le produit en suivant les spécifications. Cela peut-être un sous-traitant qui réalise pour vous la fabrication.

Enfin le “testeur” est la personne qui va dérouler les procédures de test pour s’assurer que le produit fonctionne tel qu’il a été spécifié.

Dans le meilleur des mondes, et ce monde coûte cher nous sommes tous d’accord, ces 3 personnes sont différentes. Mais en pratique, pour des questions de moyens, c’est souvent la même personne qui conçoit, développe et fabrique le produit. Donc cette personne connaît parfaitement son produit. Or si elle le teste aussi, elle pourrait, même inconsciemment, “tordre” la procédure pour faire en sorte que le test soit passant. Ou moins pernicieux mais plus dommageable pour le produit, une personne qui connaît le fonctionnement du produit aura plus de mal à le mettre en défaut. Or c’est tout l’objet des tests. Alors qu’une personne n’y connaissant rien suivra la procédure à la lettre et sera extrêmement efficace pour dénicher tous les défauts de la procédure, comme du produit.

C’est pourquoi cloisonner ces 3 étapes que sont la spécification, la réalisation et la validation permet d’éviter les biais ou les conflits d’intérêt. Cependant les différents acteurs doivent collaborer de manière très rapprochée pour éviter d’apporter de l’inertie au projet.

(Et d’où l’intérêt d’identifier la personne qui déroule les tests !)

Conclusion

Comme on vient de le voir avec cette article, concevoir et mener une campagne de test est un véritable projet dans le projet. Mais elle est indispensable pour assurer la qualité du produit.

Les documents détaillés ici sont multiples et porteraient à croire qu’ils alourdissent le processus. Il n’en est rien. Certes ils requièrent un investissement en temps au début du projet. Mais ils induisent une flexibilité accrue et donc une plus grande robustesse du processus. Les documents sont certes plus nombreux mais conséquemment plus courts et plus modulaires, ce qui rend beaucoup plus facile et rapide leur mise-à-jour.

Si le client fait légèrement évoluer son besoin, vous n’aurez alors que des modifications chirurgicales à apporter et celles-ci vous seront indiquées par les matrices de traçabilité.

Et vous ?

Comment construisez-vous vos campagnes de tests ?

Utilisez-vous des logiciels particuliers pour les concevoir ?

Quels “plans d’actions” mettez-vous en œuvre pour résoudre les problèmes identifiés par vos tests ?

Vous arrive-t-il de recycler / réutiliser des tests d’un produit à l’autre ? Voire d’un projet à l’autre ?

Quelles bonnes pratiques avez-vous identifiées au fil de votre expérience ?

Related Posts

1 Response
  1. Excellent pieces. Keep posting such kind of info on your site.
    Im really impressed by your blog.
    Hey there, You have done an excellent job. I’ll definitely digg it and for my part recommend to my friends.
    I’m sure they’ll be benefited from this site.

Leave a Reply