La recette fonctionnelle des Systèmes d'Information …
Qu'est ce que la recette fonctionnelle? Si l'on prend un dictionnaire et que l'on regarde le sens du mot recette, on obtient les définitions suivantes :
Plus simplement, la recette fonctionnelle est l'attestation qu'un contrat entre deux parties à bien été respecté.
Par conséquent, nous pouvons identifier les acteurs suivants dans notre processus de recette:
La recette fonctionnelle consiste donc pour le client à vérifier la conformité de l'objet réalisé par rapport à sa commande. Alors bien sûr le client peut décider de faire lui-même la recette du produit ou bien demander à un tiers de la faire pour lui, mais le principe reste le même.
*************************
A présent que j'ai défini ce qu'est une recette fonctionnelle, je vais essayer de vous faire comprendre les enjeux qui se cachent derrière cette recette. Pour cela je prendrais un exemple simple qui vous est plus familier je pense et surtout plus simple, du moins en apparence :
Vous avez décidé de faire construire une maison ou un appartement, vous êtes donc le client et vous demandez à un entrepreneur de vous construire votre future maison. Je vous passe les détails des négociations qui suivent, et donc l'entrepreneur réalise votre maison. Quelques mois plus tard la maison est construire et vous pouvez le constater de visu. Vous avez donc bien validé le fait que l'entrepreneur a bien construit votre maison.
Oui mais lorsque vous vous installez, vous découvrez de nombreuses anomalies : l'interrupteur qui n'est pas à la bonne place, le mur devait faire 2m il n'en fait que 1.90m et don c vous ne pouvez plus placer l'armoire de votre grand-mère…. Vous vous retournez alors vers l'entrepreneur pour lui faire constater que votre maison n'est pas comme elle devait être. Ce qui tombe bien puisque de par la loi vous avez trois mois pour contester la livraison.
La recette d'un SI passe par une même logique : je vais essayer ma maison pour savoir si tout est comme il se doit…
La recette serait par conséquent une méthode pragmative qui consiste à essayer sa maison. Mais cette méthode est longue. En effet, il faut essayer toute les options de votre maison : installer tous vos meubles, essayer vous-même votre maison mais également tous ceux qui vont y vivre… et ce dans la limite des trois mois.
Oui mais pour un SI vous n'avez bien souvent pas trois mois pour essayer votre système, il doit être mis en service à une date précise qui ne peut être modifiée. Par conséquent, il va falloir anticiper et prévoir avant la livraison comment vous allez faire la recette.
Par conséquent vous allez rationaliser cette méthode pragmative.
Vous allez donc faire un plan de recette qui liste toutes les fonctionnalités à tester, tous les cas possibles d'utilisation. Oui mais comment faire? Comment imaginer tous les cas possibles? Pour ça vous avez un support c'est le cahier des charges de votre SI ou dans le cas de notre exemple le plan de construction de votre maison et le contrat que vous avez passé avec l'entrepreneur.
Ce cahier des charges va donc vous aider à définir le cadre des fonctionnalités que vous allez devoir tester. En effet, si le plan de construction de votre maison ne comporte pas de garage, il est inutile d'envisager de tester l'entrée de votre voiture dans le garage.
Bien sûr un exemple aussi simple fait sourire, mais est-il si simple que vous l'imaginez. Tester l'ouverture de vos fenêtres. Simple, oui bien sûr mais avez vous suffisamment étudié le plan de construction ? Est-ce que vos fenêtres sont coulissantes ou bien avec un seul battant ou deux ou encore est ce que ce sont des portes-fenêtres? Et bien sur tester vos fenêtres devient un problème différent en fonction des cas.
Par conséquent vous allez devoir vous appuyer fortement sur votre cahier des charges pour définir le périmètre de votre recette.
Un plan de recette c'est donc définir l'ensemble des réactions attendues par votre SI :
Un plan de test contient donc des scénarios de test, comme un scénariste vous allez mettre sur le papier le déroulement du film qui va prochainement être tourné. Imaginons à présent un scénario simple :
Le Nom de la scène (Objectif du scénario) : Vérifier l'ouverture de la porte de votre chambre depuis votre chambre.
Les acteurs du scénario : Vous
Le décor : La chambre, le couloir de la maison et une porte fermée entre votre chambre et le couloir.
Les actions du scénario :
Voilà un scénario classique d'utilisation, mais est ce que votre travail est fini pour autant ? Non pour des soucis de qualité vous allez devoir tester un autre scénario complémentaire de celui-ci.
Le Nom de la scène (Objectif du scénario) : Vérifier la non-ouverture de la porte de chambre depuis votre chambre.
Les acteurs du scénario : Vous
Le décor : La chambre, le couloir de la maison et une porte fermée entre votre chambre et le couloir.
Les actions du scénario :
Donc vous avez testé l'ouverture de votre porte…enfin presque parce que si vous voulez vraiment être complet dans vos tests, vous allez devoir tester l'ouverture de la porte depuis le couloir, mais aussi en tournant la poignée dans le sens des aiguilles d'une montre et dans le sens inverse ou en fermant la porte à clé ou en changeant l'acteur du scénario une petite fille de dix ans ou bien boxeur poids lourd…
Nous abordons ici une notion intéressante qui consiste à dire que la qualité de la recette dépend de la quantité de scénarios que vous allez mettre au point. Enfin presque, il n'est peut être pas réaliste d'imaginer qu'un boxeur poids lourd ouvre votre porte de chambre. Et réaliser un tel test nuirait à la qualité de votre recette puisque vous aller perdre du temps pour le jouer, temps que vous pourriez utiliser pour réaliser des tests plus plausibles.
Imaginons à présent que vous avez bien travaillé et que les scénarios sont écrits.
Ce qui en fait beaucoup, il faut donc les regrouper en grande fonctionnalité pour pouvoir s'y retrouver.
Les familles de scénarios pourraient donc être par exemple :
Tester les portes, tester l'ouverture de la porte de la chambre, tester le fonctionnement normal, tester le fonctionnement anormal, tester l'ouverture de la porte du salon, tester les fenêtres, tester la fermeture de la fenêtre de la cuisine...
Une autre méthode pour classer les scénarios de test, consiste à les trier par gravité. Le principe de cette méthode est d'anticiper la gravité des problèmes résultant du déroulement des scénarios de test. Par exemple, constater que les prises électriques ne sont pas aux normes n'a pas la même gravité que constater qu'il manque un rang de carrelage dans la salle de bain.
Alors que la première erreur peut être considérée comme bloquante, la seconde n'est que mineure.
Cette méthode de classement permet de porter une attention particulière aux points cruciaux du projet. De plus, cela va permettre d'alerter le réalisateur sur l'importance de certains points.
Mais il ne faut pas confondre, gravité du scénario et gravité des erreurs. Dans les faits, d'un scénario de test peut découler plusieurs erreur dont le niveau de gravité est différent. Prenons un exemple, le scénario suivant :
Objectif du scénario : Installation de votre four dans votre cuisine
Les acteurs du scénario : Vous
Le décor : La cuisine
Les actions du scénario :
Les résultats du jeu de votre scénario peuvent être différents :
La deuxième erreur est considérée comme moins grave car vous pouvez avez des parades, installer une rallonge au niveau du câble ou bien au niveau de la prise.
Cette seconde méthode est une analyse de risque des scénarios eux mêmes. Ce principe permet comme je le disais précédemment d'alerter à l'avance les réalisateurs de l'importance de certains points, mais également de perde moins de temps lors de la recette avec les points d'erreurs déjà envisagés pour ce concentrer sur les erreurs non répertoriées.
Le dernier exemple que nous avons pris introduisait également une autre notion de la recette, que vous avez peut être entrevue… La notion de dépendance entre scénarios.
En effet le scénario d'installation du four suppose avec la première action que le meuble du four est présent dans la cuisine. Par conséquent la scène d'installation du four doit être précédée par la scène qui consiste à vérifier la présence du meuble four qui lui-même peut avoir d'autres prédécesseurs.
Par conséquent la préparation de la recette consiste également à donner les séquences d'enchaînement des scénarios. Et établir par la suite une campagne de test, c'est-à-dire un planning de la recette qui prend en compte les scénarios avec leurs contraintes de séquence, mais également les durées de réalisation des scénarios ainsi que les différentes ressources nécessaires pour l'exécution des scénarios.
Vous venez donc de finir de préparer votre recette. Pour cela vous avez fait un plan de recette qui contient l'ensemble des scénarios. Ces scénarios vous les avez regroupés en arborescence pour vous y retrouver. Vous avez également déterminé la gravité des erreurs potentielles résultant de l'exécution des scénarios de test. De plus vous avez conçu votre campagne de test en donnant un ordre chronologique dans la réalisation des tests.
*************************
Donc Tout va bien, vous avez fait la plus grande partie du travail et la plus noble, il ne vous reste plus qu'à exécuter votre recette. Rien de plus simple puisque vous avez tout préparé.
Enfin presque…
Un des problèmes les plus difficiles que vous alliez avoir à traiter est relationnel. Votre relation en tant que testeur face aux réalisateurs de votre projet.
Tout d'abord le langage employé dans la recette de SI ne vous aide pas :
Vous allez donc être mal vu par les réalisateurs parce que vous allez critiquer leurs travaux. Il est par conséquent inutile de chercher le conflit avec les réalisateurs. Ce qui est loin d'être évident :
Conscient de tous ces problèmes, il faut aborder la recette avec l'idée suivante en tête : vous allez trouver obligatoirement des erreurs… Donc autant s'y faire dès le début de la recette… Et ce demander plutôt comment faire pour que ces problèmes soient résolus rapidement.
Une première chose qui va vous aider est le catalogue des erreurs que vous avez réalisé lors de la phase de préparation de la recette. Il permet tout d'abord une identification plus rapide du problème. En effet ces erreurs ont déjà été référencées et de plus le réalisateur se sent responsable de cette erreur, il ne vous reproche plus que le cahier des charges n'était pas complet… Cela peut vous paraître anodin comme constat, mais il faut bien prendre conscience que la recette est une phase par définition conflictuelle et la présence de ce catalogue des erreurs potentielles vous permet de ne pas avoir à supporter l'éternelle discussion de la responsabilité de l'erreur.
Mais il ne faut pas se leurrer, ce catalogue des erreurs n'est pas complet. Certaines erreurs n'y seront pas référencées. Le problème consiste alors à expliquer le disfonctionnement, ce qui n'est pas toujours évidemment si par exemple le problème n'est pas constamment constaté.
Imaginons la situation suivante : vous constaté que le disjoncteur de votre maison saute par moment. Vous allez donc décider de créer une nouvelle anomalie qui explique que par moment le disjoncteur électrique s'arrête. La réponse à cette anomalie sera alors certainement : "Nous n'arrivons pas à reproduire cette erreur… Nous classons donc cette anomalie dans le dossier : Instruite sans suite". Commence alors pour vous le challenge qui consiste à déplacer votre anomalie du classeur "Instruite sans suite" à celui "Anomalie en résolution". En plus de la perte de temps, vous allez devoir entrer en conflit avec le constructeur.
La première solution qui vient à l'esprit serait d'avoir des preuves de l'anomalie. Peut être serait-il pertinent de filmer la réalisation des scénarios, vous seriez ainsi suivi par un caméraman pendant le déroulement des scénarios. Et ce principe on le retrouve dans la recette fonctionnelle. En effet il existe des automates qui réalisent vos scénarios en enregistrant toutes les opérations et qui comparent les résultats obtenus aux résultats attendus. Ces outils sont bien entendus des atouts pour les personnes qui font la recette, ils sont malheureusement encore très complexes et surtout très contraignants. De plus même si vous avez une preuve de l'anomalie, vous n'avez en rien fait avancer les choses dans sa résolution.
Une autre solution est donc une fois que vous avez constaté l'anomalie de fonctionnement de votre disjoncteur électrique, de démarrez ce que j'appelle des scénarios d'exploration d'anomalie. Ce sont bien sûr des scénarios qui n'ont pas été préparés à l'avance puisqu'ils dépendent de l'anomalie détectée. L'intérêt de ces scénarios va être de cerner de manière plus précise la nature de l'anomalie. Si vous reprenez l'exemple précédent, vous allez devoir tester les prises électriques les une après les autres ou augmenter progressivement le nombre d'appareil électrique fonctionnant en même temps…. Tous les résultats de ces scénarios ont un intérêt et pas uniquement les anomalies comme avec les scénarios classiques. Tous les résultats obtenus par vos scénarios d'exploration peuvent conduire les réalisateurs à comprendre la nature de l'erreur. Cette construction des scénarios d'exploration peut prendre souvent beaucoup de temps et vous pouvez aussi considérer que c'est le travail du réalisateur de trouver les causes de l'anomalie. Mais dans cette démarche vous n'êtes plus à la recherche des anomalies mais à la recherche d'une solution, votre relation avec les réalisateurs n'est plus conflictuelle mais collaboratrice. Une collaboration qui a pour objectif la qualité de votre future SI.
Bien entendu, le sujet du déroulement de la recette n'est pas restreint à ces seuls points que nous venons d'évoquer. Il faudrait également aborder le problème de la gestion des anomalies, c'est-à-dire des nouvelles versions du SI qui corrigent les anomalies que vous avez détectées. Ce problème étant plus ou moins important en fonction de la modularité du SI (concept objet).
Un autre sujet qu'il faudrait également aborder est l'environnement des tests, c'est-à-dire la simulation de l'environnement de production. Imaginons que vous testez votre nouvelle maison dans un environnement différent, votre maison a été déposée pour les tests en pleine campagne alors que vous allez habiter près d'une nationale. Etes vous certain de pouvoir tester correctement les problèmes d'insonorisations ? Pour ça il va falloir simuler le bruit d'une nationale et la qualité de vos tests va dépendre de cette simulation audio.
D'autres problèmes sont également à aborder pour le déroulement de la recette fonctionnelle mais l'essentielle à retenir dans ce processus est la collaboration entre les personnes qui font la recette et ceux qui apportent les modifications au SI.
*************************Certaines entreprises considèrent la recette comme un problème mineur qui consiste simplement à vérifier que "la maison est construite".
D'autres considèrent la recette comme un projet à part entière, un projet dans le projet. Dans ce cas, la recette est bien la validation du produit livrée. Mais cette vision aboutit à deux conséquences qui ne la favorisent pas. La première est que bien souvent la recette est un projet qui ne démarre qu'une fois que la réalisation du SI a débuté, ce qui est trop tard comme nous l'avons vu précédemment. La seconde conséquence est dans la nature de ce projet qui est de valider un produit, si qui implique que vous n'êtes pas dans une démarche collaborative de projet.
Une autre vision de la recette est de la voir comme faisant partie intégrante de votre projet de SI, c'est le baromètre de la qualité de votre SI. Elle doit donc se préparer dès la mise en place de votre projet. La préparation de la recette doit vous aider à établir le cahier des charges ainsi que les spécifications fonctionnelles. La recette en elle-même est un travail de collaboration entre vous et les fournisseurs qui n'a qu'un seul objectif, celui de votre projet, c'est-à-dire mettre en service un Système d'Information de qualité.