Tests de fiabilité

Qu'est-ce qu'un test de fiabilité ?

Le test de fiabilité (RT) est l'une des exigences non fonctionnelles décrites par la norme ISO 25010. Selon cette norme, la RT est le degré auquel un système, un produit ou un composant remplit des fonctions spécifiées dans des conditions spécifiées pendant une période de temps spécifiée. Elle traite de questions telles que le degré de fiabilité du système lorsque.. :

• un utilisateur l'utilise pour accomplir sa tâche
• il est mis à jour avec du nouveau contenu
• il est entretenu ou porté
• il est publié

Par conséquent, la fiabilité est principalement une question de :

• Maturité: Le degré auquel un système, un produit, un composant ou une caractéristique de qualité répond aux exigences de fiabilité dans des conditions de fonctionnement normales.
• Disponibilité: Le degré auquel un système, un produit ou un composant est opérationnel et accessible lorsqu'il doit être utilisé - la disponibilité peut être mesurée par la durée pendant laquelle le système, le produit ou le composant est opérationnel.
• Tolérance aux pannes : Le degré auquel un système, un produit ou un composant fonctionne comme prévu malgré la présence de défaillances matérielles ou logicielles.
• Récupérabilité: Le degré auquel, en cas d'interruption ou de panne, un système peut récupérer les données directement affectées et rétablir l'état souhaité du système - le temps de récupération fait également partie de cette définition.

à laquelle peuvent s'ajouter d'autres facteurs tels que la sécurité (y compris la confidentialité et l'intégrité), la maintenabilité, la durabilité et le support maintenance .

Dans l'industrie du matériel, il existe de nombreux modèles de fiabilité basés sur les différences entre les unités et le changement de performance dû à la fatigue des matériaux avec le temps [Elsayed 2012]. 

Les tests de fiabilité ne servent pas à valider un produit, ce qui nécessite un processus de simulation sans défaillance. Les tests de fiabilité sont plutôt un processus de dépistage qui nécessite une stimulation pour exposer les défauts latents des produits qui, autrement, échoueraient sur le terrain [Dodson 2006]. Idéalement, sur une chaîne de montage, ce processus de dépistage doit être appliqué à chaque unité, mais une tendance sur la fiabilité de vos unités peut émerger à partir d'échantillons. Cette approche d'échantillonnage fournira un ratio de fiabilité mais aussi un taux de confiance, plus l'échantillonnage est important, plus le ratio de fiabilité est fiable.

Exemple de démonstration de la fiabilité des tailles d'échantillon [Dodson 2006] :

‍

La fiabilité aide à prédire la qualité du logiciel en utilisant la théorie des probabilités et l'analyse statistique avec un ensemble de techniques et de modèles basés sur [Moharil 2019].

Cette approche est légèrement différente de celle de l'industrie du logiciel. Selon certains, elle n'est pas applicable aux produits logiciels [IEEE 24765:2010] [ISO25010], probablement parce que le numérique clone facilement les données et les produits. De plus, la polyvalence du système est soumise à de nombreuses versions de mise à niveau et empêche l'émergence de modèles statistiques stables. Par conséquent, la fiabilité du logiciel est décrite comme la probabilité d'un fonctionnement sans défaillance du logiciel pendant une période donnée dans un environnement assigné. De même, la fiabilité du système est la capacité à effectuer les opérations ou les fonctions requises dans les conditions données pendant une période de temps spécifiée [Moharil 2019]. Cette approche temporelle de la fiabilité est également connue sous le nom de "modèles de croissance de la fiabilité des logiciels" (SRGM). Elle est utilisée pour évaluer les fiabilités actuelles et futures. Elle peut également servir de critère de sortie pour arrêter les tests, ou pour estimer le temps ou les ressources nécessaires pour atteindre un objectif de fiabilité [Tian 2005][Moharil 2019]. Les SRGM peuvent également être perçus du point de vue du domaine d'entrée. Ces "modèles de fiabilité du domaine d'entrée" (IDRM) sont utilisés pour analyser les états d'entrée et les données de défaillance, ce qui fournit des informations précieuses sur la relation entre les états d'entrée et la fiabilité [Tian 2005][Moharil 2019].

La fiabilité est quelque chose qui se démontre au fil du temps et les tests permettent d'accélérer cette démonstration. Cependant, les experts suggèrent qu'il est impossible d'accélérer un test par plus d'un facteur 10 sans perdre une certaine corrélation avec les conditions du monde réel ; par conséquent, les tests sont un équilibre entre la science et le jugement [Dodson 2006]. 

Impact sur la maturité des tests

En matière de fiabilité, il convient d'évaluer non seulement le logiciel livré, mais aussi les services qui l'entourent. La façon la plus simple de percevoir ce point de vue holistique est celui des clients. Supposons qu'un site bug apparaisse en production et reste sans solution pendant un certain temps, les utilisateurs finaux évalueront inévitablement la fiabilité du système entre le moment où le problème apparaît et celui où il est résolu, c'est-à-dire le temps moyen de récupération (MTTR). De plus, si les problèmes apparaissent trop souvent, ils peuvent causer des désagréments même s'ils sont rapidement résolus ; cette période sans problème est appelée "temps moyen entre les défaillances" (MTBF). Les valeurs MTTR et MTBF doivent être surveillées de près. Le SRE de Google accorde une attention particulière à ces mesures de disponibilité [Beyer 2016]. Pour permettre une surveillance en temps réel de ces paramètres, des capteurs doivent être codés dans le produit et reliés à des outils de surveillance.

Malheureusement, même si cette approche basée sur les capteurs est obligatoire pour traiter les impacts négatifs dès l'apparition des problèmes, il s'agit d'une technique de test de type Shift Right; elle doit donc être complétée par des techniques de type Shift Left afin d'être proactive. Par exemple, en règle générale, le nombre de problèmes trouvés divisé par la durée de la campagne de test peut être utilisé pour évaluer les améliorations du MTBF. En effet, le véritable MTBF ne peut pas être défini à partir des campagnes de test car les lois de distribution des cas d'utilisation in vitro et in vivo ne sont pas les mêmes [Dodson 2006] ; c'est-à-dire qu'une campagne de test typique comprend quelques situations standard contre un tas de cas étranges alors que les situations réelles sont la plupart du temps des situations bien connues ; de plus, ces cas particuliers sont plus susceptibles d'apparaître après un certain temps plutôt qu'après quelques utilisations. Pour modéliser avec précision la fiabilité sur le terrain, les cas de test doivent correspondre à la fréquence d'utilisation des fonctionnalités [Dodson 2006], ce qui est économiquement difficile à réaliser.

Il est généralement admis que "les limitations de la fiabilité sont dues à des défauts dans les exigences, la conception et la mise en œuvre" [IEEE 24765:2010] [ISO25010] mais l'ensemble du système doit être considéré. Par exemple, dans une approche SLA/SLO, une alternative est d'impliquer les pires situations [Dodson 2006] pour éviter les pénalités. Cela peut ensuite être combiné avec une stratégie de budget d'erreur. Du point de vue du client, le délai de rétablissement du problème est très important car il mesure la disponibilité du système, qui peut être principalement mesurée par le MTTR. Améliorer le MTTR, c'est viser à la fois une haute résilience du produit aux problèmes et l'organisation qui gère ces problèmes, puisque la réparation du site bug introduit des retards. Lorsqu'une partie du système est défaillante, le MTTR est susceptible d'être affecté et la théorie des contraintes devrait être impliquée pour gérer le flux et l'équilibre entre ces parties. Cette vision holistique tend à prouver que les systèmes à base de logiciels sont effectivement soumis à la fatigue, notamment en raison de l'organisation humaine qui s'occupe du produit, mais notre expérience quotidienne avec les ordinateurs personnels montre que les systèmes logiciels s'usent parce qu'ils ne sont pas des automates finis et que l'entropie altère lentement les systèmes.

Dans un processus de livraison agile, le test de fiabilité sur le produit devrait être appliqué au moins aux incréments de produit selon les "quadrants de test agiles" [Marick 2003][Bach 2014][Crispin 2021]. Cette approche devrait aider à définir la NFR applicable à un US donné ou à l'ensemble du produit ; cela conduirait à introduire certains critères sur la Definition of Done (DoD).

Le point de vue d'Agilitest sur cette pratique

Comme nous l'avons vu précédemment, "l'usure ou le vieillissement ne se produit pas dans les logiciels" [IEEE 24765:2010] [ISO25010] mais lorsqu'il s'agit de tests, les scénarios de test deviennent de moins en moins efficaces selon le principe du paradoxe du pesticide [ISTQB 2018] et deviennent moins fiables du point de vue de la "mise en évidence d'un problème". Lorsqu'il s'agit de scripts de test, la fiabilité des scripts concernant les effets du vieillissement est encore plus évidente car l'automatisation conduit à des exécutions multiples et fréquentes. Dans ces circonstances, la construction d'abaques sur la fragilité des tests, comme les tailles d'échantillon de Dodson présentées ci-dessus, devrait devenir tout à fait pertinente pour une organisation donnée.

Pour améliorer la fiabilité des scripts de test, il semble que la suppression des "odeurs de code" (anti-modèles de codage) par des techniques de refactoring [Fowler 1999] réduirait l'instabilité des tests [Palomba 2017] ; en ce qui concerne les cas de test, les odeurs de test devraient également être supprimées. Voici une première liste des odeurs de test qui nécessiteraient un remaniement [Deursen 2001] :

• Odeur 1 : "Mystery Guest" - le script s'appuie sur une ressource externe
• Sentiment 2 : "Optimisme des ressources" - le script fait des hypothèses optimistes sur les ressources externes.
• Odeur 3 : "Guerre des tests" - toutes les personnes n'ont pas les mêmes résultats lorsqu'elles exécutent des tests 
• Sentiment 4 : "Fixture générale" - configurations d'essai trop génériques, trop difficiles à comprendre et trop longues à exécuter.
• Odeur 5 : "Eager Test" - le script teste beaucoup de choses, il devient difficile à comprendre et rend les tests plus dépendants les uns des autres.
• Odeur 6 : "Test paresseux" - les scripts de test sont trop proches les uns des autres et évaluent presque la même chose.
• Sentiment 7 : "Assertion Roulette" - il n'y a pas de justification pour tester les assertions de scripts ; si le test échoue, il est difficile de savoir quelle assertion a échoué.
• Sentiment 8 : "Test indirect" - le test devient bancal lorsque des composants intermédiaires sont impliqués pour affirmer les résultats.
• Sentiment 9 : "For Testers Only" - le code de production est ajouté dans un composant uniquement à des fins de test alors qu'il devrait plutôt se trouver dans une partie spécifique.
• Senteur 10 : "Égalité sensible" - affirmer le résultat attendu d'une partie des valeurs internes
• Odeur 11 : "Duplication du code de test" - le code dans les scripts est dupliqué.

Toutes ces odeurs de test cumulées aux odeurs de code participent à la fiabilité des tests.

Un autre facteur qui conduit à la fiabilité des tests est leur tolérance aux situations inattendues qui ne conduisent pas à l'échec de l'objectif du test. La stratégie visant à donner une certaine autonomie à l'automatisation est appelée Jidoka [Monden 2011], une pratique du Lean Management qui traite automatiquement les incidents pour diminuer les interventions humaines notamment sur les scripts de test [Moustier 2020].

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍