Anomalie, erreur, défaut, défaillance, … Tous ces mots, nous les avons déjà tous entendu au moins une fois au cours d’une conversation. Souvent utilisés à tort et à travers, comme tous mots de la langue française, ils ont une signification bien particulière dans le monde du test logiciel.
Voyons simplement chacun des termes :
Une Erreur
La définition donnée dans le glossaire est la suivante : « Action humaine produisant un résultat incorrect. ».
On peut la vulgariser ainsi :
Et si on simplifie au maximum :
Un Défaut
La définition donnée dans le glossaire est la suivante : « une imperfection dans un composant ou un système qui peut conduire à ce qu’un composant ou un système n’exécute pas les fonctions requises, par exemple une instruction ou une définition de données incorrecte. Un défaut, si rencontré lors de l’exécution, peut causer la défaillance d’un composant ou d’un système. »
On peut vulgariser la définition ainsi :
Exemple pour détecter des défauts : relecture de code, relecture des spécifications, relecture des campagnes de test
Une Défaillance
La définition donnée dans le glossaire est la suivante : « Écart constaté du composant ou système par rapport au livrable, au service ou au résultat attendu [d’après Fenton]; Incapacité d’un système ou d’un composant d’exécuter une fonction requise dans les limites spécifiées. Une défaillance peut être produite quand un défaut est rencontré [DO-178B] »
On peut vulgariser la définition ainsi :
Exemple de défaillance : Message d’erreur, Batch qui ne se termine pas, webservice qui retourne un code erreur ou rien du tout, erreur 404…
Une Anomalie
La définition donnée dans le glossaire est la suivante : « toute condition qui dévie des attentes basées sur les exigences de spécifications, documents de conception, documents utilisateurs, standards etc, ou des perceptions ou expériences de quelqu’un. Les anomalies peuvent être trouvées pendant, mais pas uniquement, les revues, tests, analyses, compilations ou utilisation des produits logiciels ou de la documentation applicable [IEEE 1044]. »
On peut vulgariser la définition ainsi :
Exemple : Si une spécification est un peu floue avec la possibilité d’interpréter d’autant de façon que de personne qui vont lire la spécification (MOA, développeur, testeur, …), il est possible que le développeur puisse avoir compris d’une façon et que le testeur puisse avoir compris d’une autre façon. Le testeur écrit le cas de test en fonction de ce qu’il comprend et lorsqu’il déroule la campagne de test, il relève une anomalie. Or il n’a pas forcément la vérité absolue. Le mieux étant encore de rester factuel et d’essayer de comprendre pourquoi il y a un écart en toute humilité, afin de savoir s’il y a vraiment une défaillance qui nécessite une modification du code ou s’il faut modifier le cas de test. Dans cet exemple précis, la spécification devra être mise à jour afin d’éviter de rejouer à nouveau cette situation.
J’espère avoir pu éclairer simplement votre lanterne sur ces quelques mots qui n’ont maintenant plus aucun secret pour vous. Et comme un dessin vaut mieux que mille mots :
A propos de l’auteur: Cynthia Lefevre
je suis actuellement Responsable de la Gamme Méthodes et Qualité au sein du Bureau Technique de la DSI de l’ACOSS, qui est composé de trois domaines de compétences différentes : Agilité, Identité visuelle, Test. Passionnée de Test logiciel depuis de nombreuses années, j’ai travaillé dans des environnements, et domaines très divers et variés et sur des projets simples à complexes. Mais ce que je préfère par-dessus tout c’est de faire grandir les équipes que j’accompagne au quotidien.
Une réponse
Merci pour cet article,
Les réunions 3 amigos dans le cadre du BDD contribuent grandement à éviter les écarts d’interprétation des users stories entre testeurs et développeurs.