Shift Right

Définition du décalage vers la droite

Dans le modèle Waterfall, les tests sont effectués une fois que toute l'ingénierie a été livrée. Cette stratégie conduit à une mauvaise qualité car bugs est plus difficile à détecter et à corriger, d'où la stratégie "Shift Left" (SL) du principe "Early Testing" [ISTQB 2018] pour s'occuper des tests de manière préventive au lieu de simplement réagir à ce qui est disponible.

‍

Néanmoins, faire trop de choses avant de livrer peut ralentir le flux [Reinertsen 2009] ou peut être tout simplement impossible - aucun pentest n'est possible avant que quelque chose n'ait été déployé.

Cette stratégie de "Shift Right" (SR) concerne également le principe appelé "Testing is context dependent" [ISTQB 2018]. Le test SR consiste à observer et à surveiller le produit dans l'environnement de production, et depuis que les développements sont devenus itératifs avec un déploiement régulier auprès des clients, le test en production est également une sorte de "test précoce" pour la prochaine version à venir et donc une boucle de rétroaction continue pour les développeurs à partir des expériences réelles des utilisateurs.

Le SR est le plus utile dans la culture DevOps car il permet de mélanger les préoccupations des Ops à celles des Devs.

La RS est généralement utilisée pour atteindre, entre autres, les objectifs suivants [Chokshi 2018].

• une amélioration de l'expérience client (Customer eXperience - CX) basée sur les commentaires des utilisateurs
• une possibilité d'automatisation sur un binaire plus stable avec du temps supplémentaire pour l'exécuter une fois que la partie centrale du produit a déjà été couverte par SL.
• une couverture plus large puisque les testeurs ont accès à l'ensemble du produit sans aucune pression de livraison - la RS peut être très utile lorsqu'elle est combinée avec les Dark Launches pour permettre de séparer l'urgence du déploiement et la date de sortie qui peuvent être différentes pour des raisons opérationnelles.

Vous pouvez également utiliser Canary Releasing pour donner à quelques bêta-testeurs le temps de voir comment le système livré fonctionnera sans avoir d'impact sur tous les clients si le lancement a eu un sérieux bug.

Faire de la RS n'empêche pas de faire de la SL, les deux stratégies sont complémentaires et proposent différents types de techniques de test ou en répartissent certaines à la fois dans la SL et la RS ; ainsi, les testeurs peuvent décider laquelle de ces stratégies est la plus appropriée en termes de flux, de risque et de coût de retard.

Puisque la RS se déroule en production, vous pouvez également tirer profit de la réutilisation des données capturées dans la vie réelle pour faire de l'analyse et de la veille économique afin de définir les ensembles de données les plus fréquents pour les futurs critères d'acceptation, notamment dans le cadre des ateliers 3 Amigos ou Example mapping et même utiliser l'IA pour générer des cas de test à partir des journaux [Legeard 2021].

En fait, pour certains, SR et SL ne doivent pas être distingués et sont plutôt considérés comme des "tests continus" ou même des "tests holistiques" [Gregory 2018] [Crispin 2019] [Kozlowicz 2020], parfois appelés "TestOps" [Ahmed 2020] [Dolezel 2020] et encore un autre mot à la mode "Shift Up & Spread" [The QA Lead Team 2021] qui introduit l'écoute, qui introduit l'écoute, la défense et la prise en compte de votre client [Giacometti 2021], qui sont les concepts X-Teams et Yokoten décrits plus tôt en 2002 [Ancona 2002] et [Aimetti 2011] dans le cadre du Toyota Production System.

Impact sur la maturité des tests

L'introduction de la RS peut améliorer considérablement la maturité des tests car elle débloque un grand nombre de pratiques telles que

• Perturbation volontaire du système
• Suivi de la solution pour permettre le Lean Startup
• Crowdtesting [Leicht 2017] ou Test A/B 
• Politique de traitement des anomalies
• Feedback des ressources, du métier et du business
• pentests
• et l'utilisation des outils APM 

SR est largement soutenu par les sessions Gemba, X-Teams et Yokoten.

Là encore, la maturité des tests a beaucoup à voir avec l'innovation et la créativité. Twitter, par exemple, a créé un outil de test de régression automatisé en production basé sur un proxy qui compare les réponses entre la version actuelle et la suivante déployée en mode Dark Launch [Khanduri 2015].

Le point de vue d'Agilitest sur cette pratique

SR est une pratique intéressante à introduire avec Agilitest car elle peut fournir un certain espace pour l'automatisation des tests de manière prudente : assurer l'automatisation des scripts de test de base pendant le Sprint, permettant éventuellement à Dark Launching d'exécuter des scripts supplémentaires mis à jour ou créés sur certains cas particuliers ou simplement préparer l'ensemble supplémentaire de scripts pour la prochaine version comme scripts de test de régression.

‍

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

‍