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 :
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 articl
3 Responses
Article intéressant.
Néanmoins,sur la première étape « Présence de tests? », je ne suis pas totalement d’accord. ce n’est pas parce que des tests sont existants que je me contenterais uniquement de ceux-là pour en faire , et ce pour plusieurs raisons:
– S’il n’y a pas de spécifications, ça signifie que ces tests ont aussi été écrits sans spécifications, donc je ne sais pas jusqu’à quel point ces tests sont corrects et jusqu’où je peux m’y fier.
– Quel est le niveau de qualité de ces tests? Sont-ils facilement réutilisables? Car l’expérience m’a appris que d’une équipe à l’autre, d’une entreprise à l’autre, les compétences ne sont pas les mêmes, et les tests vont de la bonne qualité à du très exotiques.
– les tests existants couvrent-ils toutes les fonctionnalités de l’application comme on pourrait l’avoir dans des spécifications / des exigences?
Pour moi avoir des tests existants est une bonne base, mais je pense qu’effectuer les autres étapes est tout aussi nécessaire et pour valider le fait de pouvoir utiliser les tests existants, que de s’assurer du niveau de couverture de ces tests.
Bonjour,
Merci pour ce commentaire qui complète bien l’article.
En effet, il faut toujours se poser la question de la qualité des tests, sont-ils à jour? Sont-ils pertinents? Sont-ils pertinents?
Néanmoins je suis régulièrement tombé sur des cas où les spécifications n’étaient pas tenues à jour… Voir perdues mais où les tests était conservés et exécutés.
Les tests constituent alors une base de travail, loin d’être idéale mais permettant de ne pas partir de rien. Les autres étapes sont ensuite également importante dans le cas où les tests ne sont pas suffisant.
OTeNoS… :’)
Enorme je m’en souviendrai hahaha !!!