Stratégie de test : décider ce qui s'exécute où
En tant que lead, personne ne vous demande d'écrire les tests. On vous demande où les tests devraient s'exécuter et ce qui a le droit de bloquer une release. Bonne nouvelle — c'est une question plus petite et plus calme qu'elle n'en a l'air.
L'idée, en une ligne
Les vérifications rapides et pas chères s'exécutent souvent. Les vérifications lentes et coûteuses s'exécutent rarement. La vitesse décide où chaque test vit. Réussissez cette seule règle et toute la stratégie se met en place.
Commencez par la pyramide des tests
La pyramide des tests n'est que la forme saine d'une suite de tests :
- Beaucoup de tests unitaires en bas — minuscules et rapides, ils vérifient un morceau isolément.
- Moins de tests d'intégration au milieu — ils vérifient que les morceaux marchent ensemble.
- Une couche mince de tests de bout en bout (E2E) au sommet — ils pilotent toute l'app comme un vrai utilisateur. Lents, et les premiers à devenir instables.
La règle que la forme vous enseigne : poussez chaque vérification aussi bas qu'elle peut aller. Les tests plus bas sont plus rapides et pointent droit sur ce qui a cassé.
Maintenant projetez-la sur votre pipeline
Voici la même idée comme un plan de ce qui s'exécute à chaque étape de votre build :
- À chaque pull request (PR) : la couche pas chère et fiable — lint, tests unitaires, tests de contrat. Gardez-la sous dix minutes, ou les ingénieurs cessent de lire le retour.
- En nocturne : les trucs lents et sujets à l'instabilité — E2E complet et la matrice cross-navigateur. Hors du chemin critique, où ça peut prendre son temps.
- À la release : une suite smoke rapide, plus une vérification que l'exécution complète de la nuit était verte.
Ce qu'est vraiment un quality gate
Un quality gate est une condition explicite, vérifiée par machine, que le code doit passer avant d'avancer. Pas un ressenti — une règle que le pipeline impose. Gardez les règles peu nombreuses et visibles : le build passe, la couverture ne baisse pas, aucun nouveau problème de sécurité critique, le smoke est vert. Tout ce qui est rouge arrête le merge.
Avancé — pourquoi la vitesse est tout le compromis
C'est tentant de tout exécuter partout, juste par sécurité. Mais une vérification de PR lente est pire qu'aucune vérification, parce que les gens apprennent à l'ignorer. Chaque décision de placement est vraiment la même question : est-ce assez rapide et stable pour garder un merge, ou assez lent et instable pour appartenir à l'exécution nocturne ? Dites ce raisonnement à voix haute en entretien et vous sonnez comme un lead.
Basé sur « The Practical Test Pyramid » de Martin Fowler et les conseils de pipeline de déploiement de DORA (dora.dev)
Toutes les leçons de Stratégie, métriques & diriger la qualité
- Stratégie de test : décider ce qui s'exécute où
- Les métriques qui comptent (et celles qui ne comptent pas)
- Construire ou acheter et défendre l'automatisation
- Mener une équipe du manuel à l'automatisation
- Conception système et les scénarios lead classiques