Tester une application sans spécifications

Je dis souvent que le principe des tests systèmes (les tests effectués par défaut par les testeurs) c’est de vérifier que le produit testé répond bien aux spécifications. Malheureusement, il arrive que le logiciel à tester n’ait pas de spécifications.

Que faire dans ce cas ? Comment tester cet OTeNoS ?

Tout d’abord il ne faut pas paniquer ! En tant que testeur on doit s’avoir s’adapter à ce type de situation, qui malheureusement, n’est pas si rare.

Dans ce cas je procède par étape. C’est un processus assez simple mais qui a toujours fonctionné pour moi.

·        La première est de vérifier s’il existe des tests systèmes. Si des tests systèmes sont présents ils peuvent être considérés comme spécification. La présence d’une campagne de test peut aisément servir de spécifications pour une raison principale : les tests systèmes vérifient des scénarios fonctionnels qui ont été validés, cela représente donc des utilisations prévues du logiciel… Comme ce que doit faire des spécifications. S’il n’y a pas de tests système il faut passer à la seconde étape.

·        La seconde étape est de se renseigner sur l’application. Cette application est-elle connue ? existe-t-il un oracle capable de dire comment elle fonctionne ? Dans ce cas il est possible de faire une documentation en fonction (ou d’écrire des cas de tests qui serviront de documentation). Dans ce cas, on se sert de la connaissance des personnes ayant travaillées sur le projet pour avoir des spécifications. Cela fonctionne assez bien si le turnover n’est pas trop important et l’application assez récente. On met alors « sur papier » les connaissances de ces personnes que l’on peut appeler « Oracle » en suivant les termes ISTQB. Si l’application n’est pas vraiment connue, on passe alors à la 3ème étape.

·        La troisième étape revient à se demander si le logiciel est déjà fonctionnel. Le produit est-il en production et utilisé ? Si oui, il faut faire une documentation à partir de la version en production. Si l’application est encore en développement alors le mieux à faire est de commencer à écrire des spécifications (ou tests servant de spécifications) dès que possible.

Tout est résumé avec le schéma ci-dessous :

Je souhaite revenir sur la 3ème étape. Il est très important de prendre la dernière version comme spécifications et ce, même si certains comportements semble être des bugs.

J’ai connu 2 projets (1 était spécifié mais le retour d’expérience reste intéressant dans son cas) où il était demandé de recoder dans un langage plus récent (ou proposer un produit différent avec les mêmes fonctionnalités) une application en production. Les anciens projets n’étaient pas documentés et les utilisateurs étaient habitués au comportement de ces logiciels.

Sur le premier projet qui était de refaire une API, le code avait été refait et certains bugs avaient été remarqués. Le nouveau code ne les comprenait plus. Les retours clients ont été très mauvais demandant leur retour car ce comportement était connu et tous les clients avaient développés des workaround pour les inclure. Leur correction a mis en échec tous les scénarios. Il a donc été décidé de réintroduire ces bugs dans le code.

Sur le second projet qui était passé d’une console à une IHM. Il avait été décidé que la recherche sur l’IHM se ferait sur un périmètre par défaut alors que sur la console lorsque l’on cherchait sur un code IATA alors le périmètre de recherche n’était pas inclus. Les clients remontaient tous les jours un « bug » disant que la recherche sur l’IHM ne fonctionnait pas car certains résultats n’étaient pas les mêmes… Pour le moment, en partie à cause de cette différence fonctionnelle, la console est toujours beaucoup plus utilisée que l’IHM web.

La conclusion est que même si ce n’est pas forcément logique ou semble être un non-sens, il ne faut pas changer les habitudes des utilisateurs (sauf sur leur demande). C’est pour cela que lorsque l’on n’a pas de spécifications il faut partir de la version en production et non essayer de faire des spécifications qui sembleraient de meilleure qualité et avec moins de bugs.

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