Erreur, défaut et défaillance

Bug, erreur, anomalie, défaut, défaillance, imprévu, mauvais comportement, crash, freeze, feature… et j’en passe. Tous ces termes sont souvent utilisés comme des synonymes pour indiquer qu’un logiciel ne fonctionne pas comme on le souhaiterait sous certaines conditions.

Dans les faits, l’ISTQB définit 3 termes spécifiques qui ont des sens bien différents et qui font régulièrement l’objet de questions à l’examen.

Ces termes sont:

Erreur, Défaut et défaillance.

L’erreur est humaine et est l’origine des défauts.

Les défauts sont des imperfections dans le logiciel. Ces défauts peuvent engendrer des défaillances mais ce n’est pas nécessaire.

Les défaillances sont des événements au cours desquels le logiciel ne fait pas ce qu’il devrait. Pour simplifier, les défaillances sont ce que nous appelons couramment Bug ou Anomalie.

Cela revient à ce schéma:

Comme vous pouvez le remarquer, l’origine des défaillances sont des défauts dont l’origine est une erreur qui est forcément humaine. Néanmoins, un défaut n’engendre pas forcément une défaillance!

Tous les défauts n’engendrent pas nécessairement de défaillances

Ce point est particulièrement important. Afin de vous en convaincre je pourrais dire qu’une erreur sur une fonctionnalité peut être couverte par des sécurités implémentées sur d’autres fonctionnalités comme des vérifications, mais même si cela est vrai, cela n’est pas aussi parlant qu’une analogie. Je vais donc passer par ce moyen avec un exemple dans la construction:

  1. Un architecte conçoit ma maison. Dans ce cadre il doit prévoir de faire des murs en parpaings. Ces derniers seront alors recouverts d’un parement décoratif en pierre.
  2. L’erreur survient lors de l’achat des matériaux. Le constructeur achète des briques rouge pour les murs
  3. On a donc un défaut, la maison a des briques rouges au lieu des parpaings.
  4. Au final il n’y a par contre aucune défaillance pour le propriétaire, en effet les murs sont aussi solides et l’esthétique inchangée car le parement cache le défaut. En fait, la seule différence est une meilleure isolation avec les briques rouges.

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.

3 réponses

  1. Bonjour,
    Désolé d’insérer un commentaire si tardivement. Si j’ai bien compris, si je veux tenter de parler « informatiquement » :
    l’erreur de compréhension entraine un défaut de codage qui peut entrainer une défaillance dans le système.

    1. bonjour
      pas forcément une erreur de compréhension. Une erreur tout court. Cela peut être une incompréhension, un oubli, une faute de frappe, une utilisation ou une modification inattendues…

Laisser un commentaire

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

Agilité

Test Agile: pensez à tester la valeur!

La « valeur » au cœur de la qualité et donc du test en Agile Lorsque l’on parle des tests en Agile on parle généralement de qualité. Les processus de tests doivent permettre « d’assurer » des livraisons de qualité. Mais, au fait, qu’entend-on par « qualité » ? Donner une définition complète et partagée par

Lire la suite »
Outils

Les outils, attention il faut bien les utiliser!

Il existe de nombreux outils pour le test (et pas seulement pour le test!). Des outils permettant la gestion des bugs et des tests (ALM, Mantis…), des outils pour l’automatisation ou l’aide à l’automatisation (Selenium, Robot Framework…), des outils pour l’intégration continue (GitLab, Jenkins…), pour le stockage de fichiers (CVS,

Lire la suite »
IA

Table ronde: L’IA pour quoi faire ?

Revivez la table ronde du lundi 12 septembre sur le sujet de l’IA dans le test! Pour discuter de ce sujet nous avons eu le plaisir d’accueillir: Participants: Et nous avons abordé ces sujets: Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Lire la suite »