Les 3 typologies de dysfonctionnement sur vos logiciels et applicatifs

Lorsque que l’on identifie une régression on agit sur le symptôme sans, pour autant, identifier la cause. Et les sources de dysfonctionnement sont multiples pour ne pas dire omniprésentes tout au long du parcours de vie de votre applicatif. Pour s’y retrouver, on considère 3 typologies de dysfonctionnements : les erreurs, les défauts et les défaillances.

Les erreurs :

Les erreurs se rencontrent en amont des développements. Elles résultent bien (trop) souvent d’une mauvaise compréhension ou appréhension du projet. Si lors de l’expression du besoin il est exprimé que la fonction A doit exécuter la fonction N et R et que le chef de projet technique comprend la fonction M et R nous sommes en présence manifeste d’une mauvaise compréhension.

L’erreur est parfois présente dans le descriptif du besoin ou pour les puristes dans le cahier des charges. Une simple faute de frappe peut conduire à un dysfonctionnement.

Il en est de même lors de la description du besoin. Si le chef de projet ou chef de projet technique n’a pas les compétences nécessaires pour exprimer ou appréhender le besoin il y a de fortes chances que le projet ne soit pas mené à bien, voire à son terme. Et pour éviter cela il faut une bonne qualité d’écoute, de la curiosité, une capacité à formaliser les échanges, de la pertinence ou encore une vision d’ensemble.

Les défauts :

Les défauts se rencontrent pendant la phase de développement et sont essentiellement dus à 2 facteurs :

• Exigence oubliée ou mal spécifiée : cela paraît évident et pourtant bien trop souvent les défauts logiciels sont liés à de la “négligence”. Admettons comme besoin : créer un tableau de performance dynamique des commerciaux à l’échelle nationale avec pour règle 1€ de CA = 1 point. Cela pourrait donner, entre autres :

Dans le cas n°1 et en cas d’égalité, c’est l’ordre alphabétique qui déterminera le classement. Si cela impacte l’obtention d’une prime est-ce pertinent ?

Dans le cas n°2 et en cas d’égalité, la place est partagée. Dans l’exemple, le deuxième l’est-il vraiment ?

Cet exemple rudimentaire illustre parfaitement la nécessité d’exprimer précisément toutes les exigences.

Mauvais codage :

Cela relève de la compétence technique mais une erreur dans le code a de fortes chances d’entraîner un dysfonctionnement et, bien souvent, une régression.

Les défauts apparaissent souvent suite à une erreur humaine qui est liée à des échéanciers souvent serrés, des architectures complexes, des technologiques qui évoluent sans cesse et ou des interactions multiples avec des applications tierces.

À noter qu’un défaut n’est pas forcément “critique” et qu’il n’entraîne pas toujours une défaillance.

Les défaillances :

On qualifie de défaillance tous les dysfonctionnements qui apparaissent lors de l’exécution du code. C’est la partie visible de l’iceberg. Elles sont souvent critiques car présentes en production avec un impact direct sur l’expérience utilisateur. À ce stade, c’est qu’il y a eu une ou plusieurs négligences au moment des tests de non régression ou un dysfonctionnement du côté de l’infrastructure.

Les défaillances peuvent être également causées par des conditions liées à l’environnement : les systèmes d’exploitations, les navigateurs …

Pour conclure.

Pour conclure : les origines de dysfonctionnement sont plus que nombreuses et cela rend les tests INCONTOURNABLES. Il est presque impossible d’éliminer les dysfonctionnements, tout l’enjeu est de les détecter le plus tôt possible pour en minimiser l’impact (coût et temps). Bien souvent “l’erreur est humaine” et le contexte de développement de logiciel ne cesse de se tendre. Pour répondre à cela, les équipes de tests se renforcent et montent en compétences mais les tests manuels auront toujours une limite : l’humain.