Shift Left

Planification

Faire son possible à tous les niveaux de l’organisation pour tenter de décaler l’effort de test en amont de la solution

Planification

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.
Shift Left Testing et types de tests
Shift Left Testing et types de tests

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).
Illustration tirée de [Moustier 2019-1].
Illustration tirée de [Moustier 2019-1].

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 : 

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.

Cartes connexes

Pour aller plus loin

  • [Firesmith 2014] : Donald G. Firesmith - AUG 2014 - "Pièges communs des tests de systèmes et de logiciels : Comment les prévenir et les atténuer : Descriptions, symptômes, conséquences, causes et recommandations" - isbn:9780133748550.
  • [État initial 2014] : www.InitialState.com - " The Cost (and Opportunity) of Product Bugs " - 2014 - https://fr.slideshare.net/initialstate/product-bug-infographique
© Christophe Moustier - 2021