Shift-left, shift-right & votre stratégie de test d'une page

L'idée, en une ligne

Attrapez les bugs le plus tôt possible, et guettez ceux que seuls de vrais utilisateurs révèlent. Déplacer les vérifications plus tôt, c'est le shift-left ; surveiller l'app en direct, c'est le shift-right.

Ce qui vit de chaque côté

• Shift-left : vérifications statiques et tests unitaires à chaque commit, vérifications d'intégration à chaque pull request — un bug attrapé quelques minutes après avoir été tapé, pas des jours plus tard. La plupart de votre automatisation appartient ici, s'exécutant dans le pipeline CI qui garde les merges.
• Shift-right : tester en production, parce que certains problèmes n'apparaissent que sous vrai trafic — releases canari (montrer le changement à une petite tranche d'utilisateurs d'abord), surveillance et alertes, et vérifications synthétiques qui exercent discrètement l'app en direct.

Ce sont des partenaires, pas des rivaux : la gauche prévient les défauts, la droite observe ceux que seule la réalité révèle.

Voyez-le à l'œuvre

Voici à quoi ressemble le shift-left dans une vraie config CI — les vérifications les moins chères d'abord, exécutées automatiquement à chaque pull request.

# .github/workflows/quality.yml -- shift-left checks on every PR
name: quality
on: [pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ruff check .          # static analysis (leftmost, cheapest)
      - run: pytest -m "unit"      # fast unit gate
      - run: pytest -m "service"   # narrow integration
      # e2e smoke + monitoring run after deploy, against prod (shift-right):
      #   canary release, synthetic checks, alerting on error rate

Lisez-le de haut en bas : les vérifications les moins chères s'exécutent d'abord et bloquent un mauvais merge ; les vérifications de l'app en direct (dans le commentaire) s'exécutent plus tard, une fois le code sorti.

Avancé — rassemblez tout en une page

Chaque sujet de ce module se retrouve dans un artefact : une stratégie de test. Pour une seule fonctionnalité, elle dit ce que vous automatiserez, à quelle couche de la pyramide (leçon 1), guidée par le risque (leçon 4), et où sur la chronologie gauche-droite chaque vérification s'exécute. L'écrire est comment vous montrez que vous savez penser comme un SDET, pas juste scripter comme un.

Basé sur des sources réputées shift-left / shift-right (Dynatrace, BrowserStack)