Perturbation volontaire du système

Le concept de perturbation volontaire du système

Traditionnellement, les tests consistent à essayer de trouver des problèmes sur le produit, ce qui est purement du Shift Left Testing. Lorsqu'il s'agit de Shift Right Testing, la qualité ne concerne pas seulement le produit mais aussi le système qui le fournit. Ce sujet est particulièrement important lorsque l'organisation se préoccupe des opérations et veut voir comment le produit et l'organisation gèrent les événements qui peuvent perturber le système et sa robustesse, en un mot, sa "résilience". La résilience est quelque chose qui peut être manipulé avec insouciance [Taleb 2012] et être capable de faire face à un "Cygne noir" [Taleb 2010]. Un tel niveau de robustesse nécessite plusieurs types de tests, comme tout autre système ENF à tester.

Pour tester cette résilience, il faut tenter de perturber le système dans un environnement similaire à la production et également en production, par exemple en désactivant certaines parties, et voir comment l'ensemble du système réagit. Même si une situation inattendue se produit, les caractéristiques de qualité attendues du produit ne devraient pas être réduites de manière significative.

En termes de Panarchie [Moustier 2020], tester la résilience du système c'est essayer d'atteindre sa phase Ω et s'assurer que le système atteindra par lui-même une phase k dans le temps le plus court et la plus petite quantité de ressources perdues.

Impact sur la maturité des tests

DevOps met en avant le paradigme "Fail big, Fail fast, fail often" [Pontefract 2018] [Shore 2004] [Khanna 2015] pour les stratégies Shift left & right car il permet de détecter les problèmes très rapidement avant que les clients ne s'en plaignent ; plus cela se produit souvent, moins les clients se plaignent.

Pour y parvenir, les testeurs peuvent injecter des fautes. Les tests d'injection de fautes (FIT) dans les logiciels peuvent être effectués au moment de la compilation, notamment en modifiant le code source pour simuler des fautes dans le système logiciel [Gillis 2019] ou en modifiant le comportement des bibliothèques [Marinescu 2009]. Cela met en évidence, par exemple, la façon dont les parties invoquées se comporteraient en cas de contexte inattendu [Shore 2004]. La stratégie de développement sous-jacente attendue est appelée "programmation défensive" [McConnell 2004] et peut être adaptée pour déclencher la procédure d'alerte appropriée.

‍

La FIT peut également se produire au moment de l'exécution d'un logiciel qui injecterait une faute dans le logiciel pendant qu'il est en cours d'exécution, sous certaines conditions spécifiques telles qu'une durée déterminée ou un calendrier [Gillis 2019], comme le " Chaos Monkey " de Netflix. Cette approche est également appelée "Chaos engineering" qui crée des turbulences et des conditions inattendues pour voir comment le système s'adapte pour compenser les défaillances locales.

La sécurité fait partie des causes de perturbation qui conduisent à des types de tests très spécifiques. Les tests de pénétration, plus communément appelés "Pentesting", font également partie des perturbations volontaires du système. Ces tests consistent à essayer de repérer les points les plus faibles du système et éventuellement d'atteindre un atout pour démontrer la possibilité de nuire davantage.

La perturbation ultime qui peut survenir dans un système est une catastrophe, qu'elle soit naturelle ou non. Pour faire face à de tels événements, les organisations matures prévoient des plans de continuité des activités et des plans de reprise après sinistre. Malheureusement, les plans ne sont que des vœux pieux tant qu'ils ne sont pas confrontés à la réalité ; de plus, les catastrophes ne se produisent pas régulièrement. Pour permettre à la solution de faire face à ces cygnes noirs, des simulations et des exercices sont généralement déclenchés pour tester le système de gestion de la continuité des activités (BCMS) [BS-EN-ISO-22301 2019] [US-NFPA 1600 2010].

Le point de vue d'Agilitest sur cette pratique

En tant que plateforme d'automatisation de scripts de test, Agilitest peut soutenir vos tentatives pour perturber le système. Ceci pourrait être fait en conjonction avec des actions d'injection de fautes faites en parallèle avec le scénario de test.

Pour automatiser complètement de tels scénarios de test de robustesse, la conception du produit devrait intégrer certains éléments de testabilité pour permettre de piloter les parties sous-jacentes selon l'architecture de l'injecteur de fautes. Cela conduirait à une qualité intégrée [SAFe 2021-27].

‍

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

‍