Pourquoi mettre en place le shift left ?

Le shift left en quelques mots

Le Shift left est un concept qui existe depuis de nombreuses années qui a fait l’objet d’un de mes premiers articles début 2017. De manière générale le shift left est la mise en application du principe « Tester tôt« .

Le shift left n’est ni un concept agile, ni une méthodologie ni même une pratique! En fait on se rapproche plus d’une philosophie ou un état d’esprit que je résumerai comme ceci: s’assurer à chaque étape de la construction que ce que l’on produit est de qualité.

Afin de s’assurer de la qualité de notre construction logicielle il est nécessaire de tester… ce qui implique évidemment de tester différemment en fonction de l’avancement de la construction. Cette diversité d’états explique en partie le grand nombre de pratiques que l’on peut considérer comme des mises en place du shift left. Je pense notamment:

  • au TDD
  • au BDD
  • à l’ATDD
  • aux revues
  • à l’automatisation qui, permet de tester plus fréquemment et donc de détecter des régressions plus rapidement
  • aux exigences non fonctionnelles (sécurité, accessibilité, adaptabilité, ergonomie, performances…) qui sont pensées en amont et peuvent faire l’objet de tests et de mesures…

La liste est évidemment incomplète et rien ne dit que dans quelques années certaines pratiques seront devenues plus emblématiques du shift left que celles que je viens de mentionner.

Les gains du shift left

Dans tous les cas les gains attendus avec le shift left restent les même:

  • Un gain de productivité

Détecter tôt des problèmes rend leur correction plus rapide. De même, cette détection précoce évite le retravail qui par essence nous arrête dans un travail pour se concentrer sur quelque chose qui n’était plus dans notre tête. Cela fait perdre du temps de correction mais aussi de construction… tout en cassant une vitesse de croisière car l’esprit humain n’est pas très bon pour changer de sujet. Pas étonnant que l’on ai mis en place des indicateurs comme le First Pass Yield.

  • Un gain de qualité

On construit ce qui est attendu et souhaité. Même dans le cas où l’on propose moins, on se retrouve à proposer juste et donc mieux.

  • Un gain en moral

C’est ici principalement un gain pour l’équipe. Cette dernière passe moins de temps sur des tâches généralement peu appréciées comme la correction d’anomalie pour travailler sur l’amélioration du produit. Cela engendre d’ailleurs un cercle vertueux les équipes heureuses étant plus productives et investies! Enfin, une équipe heureuse est une équipe plus stable avec moins de turn-over… quand on sait que le recrutement est un sujet très tendu actuellement il est préférable de garder ses éléments.

  • Un gain de temps

C’est un peu une conséquence du gain de productivité mais cela reste important car le shift left permet de dégager du temps. Ce dernier peut être ensuite investit dans des tâches à plus forte valeur ajoutée, de la veille ou encore de l’innovation pour se démarquer de la concurrence

Conclusion

Le shift left n’est plus une option. Je ne connais pas d’équipe où cette notion n’est pas mise en place au moins de manière partielle à travers des pratiques qui lui sont liées. Néanmoins même si la très grande majorité des acteurs est conscient de cette nécessité, une mise en place « totale » (mettant en place plusieurs pratiques bien implémentées et entraînant une synergie) s’avère souvent complexe. Cela s’explique souvent par « un manque de temps » pour ces investissements, une « qualité suffisante » ou des « freins au changement ».

Même si toutes ces explications sont compréhensibles il reste important de les mettre en perspective avec les gains du shift left pour savoir si le jeu n’en vaut finalement pas la chandelle car:

  • le shift left peut répondre au problème de manque de temps des équipes,
  • avoir une productivité supérieure à niveau de qualité égal reste forcément intéressant
  • le shift left peut permettre de mettre un pied à l’étrier du changement qui est obligatoire si l’on ne veut pas disparaître.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Une réponse

  1. Marc,
    En phase avec le contenu de l’article ! Surtout sur l’impact positif, le moral à la hausse des équipes ( Dev, QA, Produit,…) suite à la mise en place du “shift left” 👍

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Agilité

4- Problèmes sur les US : leurs critères d’acceptation

Nous avions suggéré lors de la présentation de l’ATDD automatisé que nous puissions assimiler les principes agiles pour les US de la manière suivante : Les scénarios de test peuvent, quant à eux, se présenter textuellement sous la forme Gherkin : “Etant donné que … Quand … Alors”. Cette décision

Lire la suite »
Bug

[A4Q] Testers under test : les bugs mentaux des testeurs

Retrouvez la présentation de Zoé Thivet et découvrez, à travers 9 mini jeux / exercices (pouvant servir d’Ice Breaker ?) des biais communs aux testeurs. Axée sur la psychologie des tests, cette présentation interactive s’intéresse à un applicatif assez buggé : le cerveau des QA. Etablissons une liste de bugs

Lire la suite »
Agilité

Livre CFTL – Ingénieur QA dans l’agilité à l’échelle

En rejoignant Amadeus, j’ai eu l’opportunité de rejoindre un projet récent qui proposait un changement majeur: la migration vers les méthodes Agiles.  Le fait de débuter avec une nouvelle méthodologie dans un nouveau projet est intéressant, car cela a permis d’innover sans cesse, sans impacter négativement le projet.  Le projet

Lire la suite »