Nous contacter au +33 1 84 20 44 13

Les tests logiciels pour identifier les causes racines des dysfonctionnements.

La question peut paraître étrange et pourtant elle a tout son sens. Bien souvent lors de la mise en place des tests logiciels, qu’ils soient fonctionnels, unitaires ou de non régression les équipes oublient le rôle premier de l’exécution de ces tests.

Les tests sont utiles pour réduire les risques d’occurrence de dysfonctionnements dans l’environnement opérationnel, pour mesurer la qualité des logiciels, pour atteindre des normes industrielles spécifiques …

Ils sont incontournables et on ne cesse de le répéter : il faut tester, tester et encore tester. Seule certitude, les tests vont faire apparaître les dysfonctionnements mais est-ce bien leur VRAI rôle ?

Si l’on s’arrête de tester, identifier et corriger, on est dans un schéma du type “j’ai mal à la tête, je prends du paracétamol et je n’ai plus mal”. Ce n’est pas pour autant que le lendemain, dans une semaine, dans un mois je ne me retrouverai pas dans cette même situation car, en agissant ainsi, j’ai occulté la cause de mon raisonnement : pourquoi ai-je des maux de têtes ?

Pour les tests, c’est exactement la même chose. Dans bien trop de cas, on teste, on identifie un dysfonctionnement et on le corrige sans pour autant remonter jusqu’à l’origine de ce dernier. Pourquoi ce dysfonctionnement à ce stade du projet ? Et pourtant, c’est ça le vrai rôle des tests : identifier les origines des dysfonctionnements.

Pour remonter à l’origine, on commence par catégoriser le dysfonctionnement rencontré :

  1. Erreurs
  2. Défauts
  3. Défaillances

Nb : pour comprendre la différence de ces nuances, voir notre article sur les typologies de dysfonctionnement.

L’objectif est de déterminer où le dysfonctionnement a été rencontré : lors des tests unitaires ? lors des tests de non régression ? ou lors de la supervision applicative ?

Il sera, bien entendu, plus facile de remonter à l’origine du dysfonctionnement si ce dernier apparaît au début du processus de développement.

CloudNetCare_Visuels_articles_1

On ne corrige pas le défaut mais la cause racine.

Les causes racines, bien que nombreuses, sont souvent les mêmes. Dans la majorité des cas on retrouve :

  • Une incompréhension : manque de spécification, faute de frappe, défaut de vérification …
  • Un manque de temps : que des tests unitaires, couverture limitée …
  • Un budget limité : tests manuels insuffisants, automatisation d’une seule partie des tests, environnement restreint …

La difficulté est de fixer des priorités d’actions et d’être conscient des limites des tests effectués. En remontant systématiquement à la racine des dysfonctionnements vous devriez diminuer le pourcentage de dysfonctionnement de projet en projet.

Le graal, l’objectif mythique étant de conduire des développements logiciels sans rencontrer le moindre dysfonctionnement.

Pour conclure

Les tests sont inhérents à la réussite d’un projet de développement de logiciel ou d’applications. On ne peut se contenter de tester à la fin du processus de développement. Il faut absolument intégrer les tests tout au long de la fabrication du logiciel. Et, surtout, à chaque dysfonctionnement il faut prendre le temps nécessaire pour remonter à la cause racine pour que l’erreur, le défaut ou la défaillance rencontrée n’apparaisse plus sur ce projet, ni dans un autre !

Les dernières actualités

ESSAYER GRATUITEMENT
2019-03-13T17:33:48+01:00