Les 7 principes du test: L’illusion d’absence d’erreur (7/7)

Dans cette série vous pourrez trouver dans chaque article une présentation d’une des 7 principes fondamentaux du test.

L’illusion d’absence d’erreur

Description

Ce principe est peut être le plus difficile à aborder. Il est également malheureusement assez compliqué de le repérer, si l’on ne communique pas assez avec les acteurs liés au logiciel, avant un déploiement en production… Cela est le cas justement parce que lorsque l’on est dans un cas d’illusion d’absence d’erreur, on exécute ses tests et que leurs résultats nous laissent penser qu’il n’y a pas de problème. Le problème vient en fait des tests eux mêmes qui se trouvent, dans ce cas, être des tests qui sont « hors sujet ».

Les tests peuvent être vus comme « hors sujet » car ils ne vérifient pas ce qui est vraiment attendu. Leur exécution nous fait donc croire qu’il n’y a pas de bug alors qu’au final on n’a aucune information sur les résultats sur l’utilisation réelle du logiciel.

Cette exécution nous donne donc une « illusion d’une absence d’erreur » ou d’absence de défaut.

Si l’on reprend l’analogie de la pêche utilisé lors de cette série on peut faire le meilleur filet du monde pour attraper des homards il n’aurait aucun intérêt pour un enfant qui souhaite attraper des crevettes et qui aurait dans ce cas besoin d’une épuisette: plus maniable et avec des mailles plus petites permettant de vraiment attraper des crevettes.

Conséquences

Ce principe nous rappelle que les tests doivent correspondre à son utilisation réelle ou à des usages spécifiques liés à un besoin concret. En fait on est ici sur quelque chose souvent semblable à la différence entre tests système et tests d’acceptation. Faire un « produit bon » (ou de bonne qualité) ne veut pas dire faire le « bon produit ».

Pour éviter ce type d’erreur il est primordial de bien comprendre le contexte mais aussi d’encourager la communication avec les représentants métiers, connaître les retours et attentes des utilisateurs, savoir exactement quel sera le rôle et l’objectif du logiciel développé. Des bonnes pratiques comme le BDD sont justement mise en place pour éviter ce type de problématique.

Ce qu’il faut retenir

Ne partez jamais bille en tête avec vos certitudes avant de concevoir et exécuter vos tests! Le faire est la quasi certitude de tomber, au moins en partie, sur le phénomène d’illusion d’absence d’erreur. Pour bien tester il est primordial de connaître les attentes et les environnements liés au logiciel à tester. Il ne sert à rien de multiplier ses tests sur Chrome si l’ensemble des utilisateurs utilise Firefox pour des raisons de politique d’entreprise!

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

conférence

La JFTL 2023: quand la nouveauté rime avec engouement

La JFTL de tous les records La JFTL 2023 a pris fin mardi 13 juin après avoir proposé 1 journée de tutoriels le lundi et une journée de conférence le mardi. Cette année la fréquentation a battu des records avec plus de 250 participants aux différents tutoriels et 1300 inscrits

Lire la suite »
Agilité

15 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (3 / 3) 

Prenons l’exemple de la fonctionnalité F représentée par le schéma ci-dessous : Voyons comment traduire ce graphique dans une table ATDD qui nous fournira systématiquement les scénarios de test et, accessoirement, montrera comment les exigences fonctionnelles pourraient s’énoncer en Gherkin comme des RG de haut niveau. Réaliser une table ATDD

Lire la suite »
Agilité

Tests logiciels et Agilité à l’échelle

Si vous travaillez dans des contextes Agiles , vous devez de plus en plus souvent gérer non plus une seule équipe, mais plusieurs équipes collaborant à un incrément du système. Leurs activités se recoupent sur des thèmes/features communs. Au-delà des tests réalisés par chaque équipe Agile, les tests inter-équipes, c’est-à-dire transverses

Lire la suite »