Faire la recette d’un logiciel d’entreprise : les tests à faire avant de l’utiliser au quotidien

La recette d’un système de gestion échoue presque toujours de la même façon : on convoque ceux qui vont l’utiliser, on leur dit « testez-le », et les gens testent ce qu’ils savent déjà faire. Le logiciel passe. Puis, le premier jour de travail réel, arrive la commande à annuler après l’expédition, et ça, personne ne l’avait testé.

Faire la recette, c’est écrire d’abord ce qui doit se passer, puis vérifier que cela se passe. Toute la différence entre les deux tient dans le mot « d’abord ».

Un scénario de test, ce n’est pas « tester le programme »

Un scénario comporte quatre parties, et s’il en manque une, le test n’est ni reproductible ni discutable.

• Les données de départ : quel client, quelle commande, quel stock, avec quelles valeurs.
• Le rôle : qui l’exécute et avec quelles permissions.
• Les étapes : ce que l’on fait, dans l’ordre où on le fait.
• Le résultat attendu : ce qui doit être vrai à la fin, écrit avant d’exécuter.

Le résultat attendu est la partie qu’on saute, et c’est la seule qui compte. Sans elle, le test se termine par « il me semble que ça marche », qui n’est pas un résultat mais une impression, et qui ne peut ni être contesté ni confirmé.

Un plan de recette : l’affaire

Exemple illustratif sur un module qui gère les affaires. Les tests sont choisis pour couvrir les trois types toujours nécessaires : le cas normal, l’exception et ce qui doit être empêché.

Les trois dernières lignes sont celles que l’on oublie toujours. Un système se juge aussi à ce qu’il refuse, et le refus doit être compréhensible : une opération bloquée sans explication provoque les mêmes appels téléphoniques qu’une erreur.

Les tests auxquels personne ne pense

• Les opérations non autorisées, testées réellement avec l’utilisateur limité et pas seulement lues dans le tableau des permissions. Il faut aussi contrôler les impressions et les exports, par lesquels les données confidentielles sortent plus souvent que par les écrans.
• Les données sales : noms avec apostrophes, adresses très longues, montants à zéro, pièces jointes volumineuses, lignes en double.
• Les interruptions : la connexion qui tombe en pleine sauvegarde, deux personnes qui modifient le même enregistrement, la même opération envoyée deux fois.
• Les intégrations quand l’autre système ne répond pas : ce que voit l’utilisateur, ce qui reste en suspens, ce qui se passe quand l’autre système redevient disponible.
• Les moments de clôture, si le logiciel les traite de façon particulière.

Classer les anomalies au lieu de les lister

Une liste de soixante signalements sans classification bloque le projet : personne ne sait par où commencer et chaque réunion devient une négociation. Quatre catégories suffisent, définies avant de commencer.

• Bloquant : empêche de travailler et il n’existe pas de solution de contournement. Doit être corrigé avant le démarrage.
• Grave : on peut travailler, mais avec un détour long ou un risque d’erreur. Doit être corrigé avant le démarrage ou juste après, avec une date.
• Mineur : gêne, forme, texte peu clair. Se rassemble et se corrige par lot.
• Nouvelle demande : ce n’est pas une anomalie, c’est une fonction qui n’était pas prévue. Doit être reconnue comme telle et évaluée à part.

La distinction entre cette dernière catégorie et les autres est celle qui sauve le projet. Confondre une fonction manquante avec une anomalie fait porter le coût sur celui qui développe et le retard sur tout le monde, et transforme la recette en chantier sans fin.

Vérifier les corrections sans casser le reste

Chaque correction doit être vérifiée par celui qui a ouvert le signalement, pas par celui qui l’a résolue, en réexécutant le test original et non un test similaire. En parallèle, il faut répéter un groupe restreint de tests sur les parcours principaux : les corrections entraînent des effets de bord, et c’est normal que cela arrive.

Il vaut mieux fixer un nombre limité de livraisons pendant la recette — par exemple une par semaine — plutôt que de corriger en continu. Tester un système qui change sous la main rend chaque résultat peu fiable et chaque signalement discutable.

Démarrage, assistance et voie de retour

1. Décidez comment vous démarrez : tous ensemble, un département à la fois, ou en parallèle avec l’ancien système pendant une période définie. Le parallèle est plus sûr mais double le travail, il faut donc lui fixer un terme écrit.
2. Établissez qui répond dans les premiers jours, où l’on écrit et en combien de temps on répond. Les deux premières semaines génèrent plus de questions que tout le reste de l’année.
3. Définissez la voie de retour : à quelles conditions on fait marche arrière, qui le décide, et ce que deviennent les données saisies entre-temps. Si cette réponse n’existe pas, le démarrage est un pari.

Ce que ce guide ne couvre pas

Ici, il est question d’accepter des processus au résultat prévisible : pour une entrée donnée, le système doit faire une chose précise, toujours la même. La vérification de systèmes qui répondent de façon probabiliste — assistants et répondeurs automatiques, où la même question peut recevoir des réponses différentes et où la justesse est une question de degré — exige une méthode différente, traitée ailleurs. Le choix de ce qui entre dans la première version d’un système de gestion a lui aussi son propre guide.