Glossaire · Fondamentaux du test
Shift-left testing
Également appelé : shift left, shift-left, test en amont, approche shift-left
Définition
Déplacer les activités de test et de qualité plus tôt dans le cycle de livraison, pour prévenir les défauts ou les détecter quand ils coûtent le moins cher à corriger.
Le shift-left testing consiste à faire le travail de qualité plus tôt : à gauche d’une frise chronologique qui va des exigences à la mise en production. Au lieu d’une phase de test une fois le développement terminé, testeurs et développeurs relisent les exigences, s’accordent sur les critères d’acceptation, écrivent les tests automatisés en même temps que le code et les exécutent à chaque commit. Un défaut trouvé lors d’une revue des exigences coûte une conversation ; le même défaut trouvé en production coûte un incident.
À quoi cela ressemble en pratique
- Affinage (refinement). Un testeur demande « que se passe-t-il si le code promo a expiré ? » avant qu’une seule ligne de code n’existe, et la réponse devient un critère d’acceptation.
- Conception. La testabilité est discutée en amont : test IDs stables, endpoints d’API pour injecter des données, feature flags.
- Développement. Les tests unitaires et d’API sont écrits avec la fonctionnalité, pas des semaines plus tard. L’analyse statique et le linting tournent dans l’éditeur et sur les pull requests.
- CI. Chaque pull request exécute les suites rapides, et un échec bloque le merge.
Shift left ou shift right
Le shift-right testing est l’idée complémentaire : apprendre de la production grâce au monitoring, aux déploiements canary, aux feature flags, aux contrôles synthétiques et aux tests A/B. Certaines défaillances, comme les profils de trafic réels ou les pannes de services tiers, n’apparaissent qu’en production. Les équipes matures font les deux. Le shift left n’est pas une raison pour cesser d’observer ce qui se passe après la release.
Erreurs fréquentes
- Renommer sans rien changer. Si les testeurs reçoivent toujours un build terminé assorti d’une échéance, rien n’a bougé. Le vrai critère : les conversations sur la qualité ont-elles lieu avant l’écriture du code ?
- Faire faire tous les tests aux développeurs seuls. Le shift left répartit les tests dans toute l’équipe ; il ne supprime pas le besoin de compétences en test. Les testeurs évoluent souvent vers le coaching, la conception des tests et la création d’outillage.
- Ne décaler que l’automatisation. Exécuter plus tôt les tests d’interface aide, mais les plus gros gains viennent généralement de la clarification des exigences et du déplacement des vérifications vers les niveaux unitaire et API.