Shift Left

La définition de Shift Left

Quel que soit le nom que vous donnez aux pratiques de qualité logicielle, il existe principalement quatre classes de styles de test pour tout artefact :

1. Prévenir bugs avant qu'il ne soit introduit dans l'artefact
2. Examen de l'artefact en cours de construction.
3. Révision de l'artefact une fois qu'il est prêt à être livré aux clients - révision statique et dynamique.
4. Suivi dynamique de l'artefact une fois qu'il est livré au client - voir Shift Right.

Le principe de test "Early testing" [ISTQB 2018] concerne les tests dès que possible, c'est-à-dire les tests de type A si possible, éventuellement B si les testeurs peuvent participer au processus d'idéation du produit. L'idée de " Shift Left Testing " consiste à tirer l'effort de test vers A, autant que possible, c'est-à-dire à déplacer l'effort de test sur le côté gauche du SDLC. Cependant, avec le développement agile, le produit est construit de manière itérative, ce qui signifie que les types C et D participeront aux "tests précoces" pour l'incrément de produit suivant. 

Par conséquent, la stratégie de test précoce doit être considérée comme une réalisation et une amélioration continues des tests, où que ce soit dans le SDLC. Ainsi, le modèle du fromage suisse [Reason 2006] peut être utilisé pour gérer la norme de qualité appropriée à appliquer en fonction du contexte [Bach 2019] :

• les contrôles existants peuvent être renforcés pour réduire les trous dans les tranches de fromage
• des contrôles supplémentaires peuvent être ajoutés s'ils sont plus appropriés ou moins chers (loi de Pareto).

‍

Le modèle du fromage suisse met en évidence la nécessité de combiner les tests, ce qui est confirmé par le tableau ci-dessous qui fournit un pourcentage moyen de défauts trouvés dans les tests statiques de type C [Firesmith 2014] :

Pourcentage moyen de défauts détectés en fonction de la méthode de vérification statique et du type de défaut [Firesmith 2014].

En combinant statique et dynamique, l'efficacité totale n'atteindrait que 99,27%.

Ce chiffre peut sembler juste, mais il ne tient pas compte de l'impact financier qui se cache derrière : entre 22,2 et 59,5 milliards de dollars par an [NIST 2002] [Firesmith 2014] ou même jusqu'à 113 milliards de dollars sachant que seulement 30 milliards de dollars permettraient de mettre fin à la faim dans le monde [Initial State 2014].

Pour relever la barre en matière d'identification des défauts, nous devons nous attaquer au diable caché dans chaque détail grâce à de nombreuses techniques de test qui offrent différentes perspectives sur l'élément que nous voulons tester, conformément au principe " Testing is context dependent " [ISTQB 2018], tout comme vous feriez le tour d'une voiture pour inspecter les défauts lorsque vous l'achetez.

Un autre avantage du test shift left est que les exigences non fonctionnelles (NFR) sont prises en compte très tôt. Ceci est extrêmement important car les NFR font partie des "Architecturally Significant Requirements" (ASR) [Chen 2013], c'est-à-dire qu'elles ont un impact considérable sur l'aspect de l'architecture.

Impact sur la maturité des tests

Ce que l'on appelle le "test continu" est une série combinée d'activités et d'états d'esprit qui comprennent : 

• Introduire les tests le plus tôt possible, notamment par le biais de la testabilité du backlog de produit.
• Idéation de produits en groupe avec des ateliers tels que 3 Amigos
• Built-in Quality to Prevent bugs [SAFe 2021-27] notamment grâce à

• une conception testable pour permettre la testabilité dès que possible des parties du produit et des harnais d'essai pour évaluer ces parties
• un mécanisme Fail Fast
• y compris l'automatisation des observables pour préparer les tests de type D et la surveillance de la solution déployée sur les ressources, le domaine et l'entreprise.

• test souvent avec la chaîne d'outils d'intégration continue (CI) grâce aux tests unitaires, aux critères d'acceptation et à tout autre script de test automatisé [Devopedia 2021].
• Tests de bout en bout le plus tôt possible, avant même que le système entier ne soit disponible.
• Une fois le produit déployé, vous pouvez également perturber volontairement le système ou déclencher un test de votre plan de reprise après sinistre (PRS) pour voir dans quelle mesure il est résistant aux perturbations et préparer un plan de remédiation si nécessaire avant l'arrivée de véritables pannes.
• Enfin, les rétrospectives sont également un bon moyen de tirer profit de l'expérience acquise et d'améliorer le système afin d'éviter que des problèmes ne se produisent.

Chaque fois qu'un test est effectué pour prévenir certaines situations indésirables, il devrait y avoir une sorte de connaissance de la gouvernance qui devrait vous guider, au-delà des exigences simples et explicites. C'est ce qu'on appelle "l'apprentissage en double boucle" [Argyris 1977]. Plus vous essayez d'anticiper, plus ces exigences explicites peuvent être floues. C'est pourquoi X-Teams et PanTesting devraient être d'une grande aide pour plonger encore plus dans la question du Shift Left.

Le point de vue d'Agilitest sur cette pratique

Puisque Agilitest est conçu pour les tests fonctionnels de bout en bout, Agilitest est généralement impliqué à la fin du SDLC et il y a un risque que ces tests retardent la livraison du produit ou diminuent le flux ou se produisent après le Sprint et le déploiement.

Le décalage à gauche est extrêmement précieux lorsqu'il s'agit de l'automatisation des scripts de test car il vous donne la possibilité d'exécuter vos tests pendant le Sprint. Cette stratégie de test mène vers certaines pratiques agiles au moins en ce qui concerne la collaboration de l'équipe [Subrahmanyam 2021] parce que le test à la fin semble être un piège [Firesmith 2014][Magowan 2020].

‍

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

‍