Avant de parler du shift right il faut d’abord connaitre le shift left et identifier ses limites dans le contexte actuel et plus particulièrement dans l’optique du déploiement continu.
La limite du shift left :
On parle beaucoup du shift left. J’en ai d’ailleurs fait le sujet d’un de mes articles.
Pour rappel, le shift left c’est la prise de conscience du 3ème principe des tests « Tester tôt ». C’est donc mettre le test au centre du projet et ce dès les phases d’expression de besoin. Le résultat est une amélioration de la qualité et une réduction des coûts de correction (plus on détecte une anomalie tôt, moins elle coûte cher).
Le shift left peut donc se présenter comme ci-dessous avec du test tout au long du projet :
….
Tout au long du projet … On peut (potentiellement) l’affirmer avec un cycle en V classique. Néanmoins, dès le moment où on utilise des méthodes itératives avec des mises en production régulières cela perd une bonne partie de son sens, l’application étant encore en développement mais aussi en production avec des contraintes de production et notamment des bugs de production.
Le shift left affiche donc ses limites. Cette limite est la production !
L’avènement du shift right ?
Afin de dépasser la limite du shift left il faut pouvoir aller plus loin que ce dernier left et dépasser le cycle habituel d’un projet en poussant les tests jusqu’à la production !
On appelle cela le shift right ! Le test ne se cantonne donc plus au « cycle projet » mais va au-delà pour atteindre « cycle de vie du produit » :
Vous vous en êtes sûrement aperçu on se rapproche fortement du DevOps qui vise à casser les silos, à faire communiquer les développeurs et les exploitants.
Avec le shift right on peut parler de DevTestOps ! Pour profiter pleinement des avantages du shift right il faut pouvoir faire des mises en service rapides et fréquentes.
Dans les faits le shift right c’est pousser les tests jusqu’à la production et donc tester en production également !
Pour cela il faut recueillir de nombreuses informations comme :
- Les logs (ex : analyse des erreurs…) et des mesures (ex : temps de réponse…) en production
- Connaitre et monitorer les performances de l’application
- Savoir comment l’application est utilisée
- Connaitre les bugs de production
- Connaitre les retours clients le plus vite possible…
Toutes ces informations sont essentielles afin d’améliorer sa stratégie de test. Pourquoi passer beaucoup de temps à tester des fonctionnalités non utilisées au détriment d’autres fonctionnalités (avec des anomalies) très appréciées des utilisateurs ?
Le shift right permet également d’avoir des retours en temps réel et de pouvoir répondre plus rapidement aux problématiques des clients. Des corrections rapides d’anomalies sont généralement très bien vues par les utilisateurs !
Le site du journal Ouest France fonctionne avec peu de tests système mais les équipes font énormément de monitoring pour faire des rollback très rapide au besoin, de nombreux « hotfix » sont faits.
De même, le monitoring permet de mesurer l’impact des fonctionnalités ajoutées.
Conclusion :
Après avoir fait le travail du shift left, il est temps de finir de transformer le test en une activité 100% transverse en poussant les tests jusqu’à la production, c’est-à-dire en passant au shift right !
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
La taverne du testeur 
hey there and thank you for your info – I have definitely picked up anything new from right here. I did however expertise a few technical issues using this website, as I experienced to reload the web site lots of times previous to I could get it to load correctly. I had been wondering if your web host is OK? Not that I am complaining, but slow loading instances times will very frequently affect your placement in google and could damage your high quality score if ads and marketing with Adwords. Anyway I’m adding this RSS to my email and could look out for a lot more of your respective interesting content. Ensure that you update this again soon..
J’aimeAimé par 1 personne
Hello,
thank you for this feedback on articles and performances.
It is painful to hear that there are performance issues on this blog. Unfortunatelly we are not responsible of this as everything is managed by WordPress. We only take car of the design and the articles on it. I hope it was just a temporary issue and that no one will face it again.
Don’t hesitate to comment again if it happens again.
J’aimeJ’aime
[…] Le shift right est le fait de continuer à tester/mersurer même en production afin d’avoir des retours sur le comportement du logiciel en production: […]
J’aimeJ’aime
Bonjour,
J’ai l’impression que dans les exemples qui sont donnés (Savoir comment l’application est utilisée, connaître les retours clients), on ne déroule pas de scénario de test sur la production, on ne fait que analyser les logs générés par l’activité utilisateur ? Si c’est bien le cas, il s’agit plutôt du monitoring, et pas du test, non?
Après je partage que l’on peut dérouler des scénarios de test pour mesurer la performance avec la vrai charge utilisateur, on peut aussi faire faire des tests par de vrais utilisateurs, comme ce que fait facebook avec le canary release qui ouvre d’abord les nouvelles fonctionnalités à ces employés.
J’aimeAimé par 1 personne
Le test peut prendre différentes formes, le monitoring en fait partie pour le shift right. Il est également possible d’avoir des sondes ou de faire des tests (scriptés ou non) sur la production.
L’idée est de bien connaitre le produit en production.
J’aimeJ’aime