Conception de tests : une compétence essentielle de l’assurance qualité
L'une des principales idées reçues dans le paysage actuel des tests est que les tests en production ne requièrent que trois ensembles de compétences : l’expertise des processus, la connaissance des outils d’automatisation des tests et les capacités de gestion des incidents. Celles-ci sont importantes, mais ce qui est visiblement absent — non seulement de cette liste mais aussi de l’esprit des responsables du recrutement — est quelque chose qu’on pourrait pourtant croire fondamental :
La capacité à concevoir un test pratique pour les environnements de production.
Ce serait risible si ce n’était pas aussi inquiétant de constater que presque aucune organisation ne privilégie l’expertise des compétences clés en assurance qualité (QA) lorsqu’elle met en place des stratégies de test en production.
Que le test soit exécuté manuellement ou de façon automatisée dans un système de production en direct, il faut avant tout savoir concevoir un test fournissant des enseignements exploitables sans perturber l’expérience utilisateur, n’est-ce pas ?
Ce serait risible si ce n’était pas aussi alarmant de voir que presque aucune organisation ne priorise l’expertise en conception de tests lors de la mise en œuvre de stratégies de test en production. Que le test soit effectué manuellement dans un environnement contrôlé ou automatisé dans un système de production en direct, il faut d’abord savoir en concevoir un qui apporte des informations pertinentes sans perturber l’utilisateur, n’est-ce pas ?
Il y a un problème évident à exclure l’expertise en conception de tests de votre approche des tests en production :
N’est-il pas essentiel de savoir que la personne qui implémente les tests dans votre environnement de production comprend ce qu’est un test pertinent ?
Puisqu’automatiser des tests mal conçus en production vous fournit rapidement des données peu fiables tout en générant des risques inutiles ? Et être « agile » tout en testant incompétemment en production ne me semble pas constituer une véritable amélioration, sauf peut-être pour le scrum master.
L’importance et la discipline de la conception de tests, en particulier dans le contexte du test en production, doivent aujourd’hui faire l’objet d’un véritable renouveau. Considérez ceci comme ma contribution à cet effort.
Ce qui est essentiel pour des tests en production efficaces
La première étape pour maîtriser les tests en production consiste à opérer certaines distinctions fondamentales qui seront sans doute déjà familières intuitivement à la plupart des spécialistes QA, mais qui sont rarement présentées de manière systématique dans le contexte du test en production.
Explorons ensemble ces concepts fondamentaux qui transformeront votre approche du test en production.
Fonctionnalité explicite vs implicite dans les environnements de production
Commençons par la distinction capitale entre fonctionnalité explicite et fonctionnalité implicite lorsque l’on teste en production.
La première correspond à ce que la plupart d’entre nous entendent par « fonctionnalité ». Elle se réfère aux fonctionnalités et capacités formellement définies par le Product et dont la spécification guide leur mise en œuvre par l’Engineering. Lors des tests en production, ces fonctions explicites sont généralement la priorité des outils de monitoring et d’observabilité.
Pour cette raison, tester la fonctionnalité explicite en production peut sembler simple, mais même pour des fonctionnalités bien définies, ce n’est pas le cas, comme nous le verrons plus tard. Au moins, le degré de spécificité des fonctionnalités explicites facilite la construction d’un échafaudage de tests en production autour d’elles (ou l’illusion de cet échafaudage).
La fonctionnalité implicite dans un environnement de production est une tout autre histoire.
Elle consiste en des comportements et des réponses à des entrées utilisateur ou environnementales qui n’étaient pas formellement définis ou anticipés. Le fait de ne pas concevoir correctement des tests pour cette fonctionnalité implicite en production est, de loin, la première cause des bugs critiques découverts après la mise en ligne du produit (l’autre étant l’insuffisance des tests sur du matériel, logiciel ou des dispositifs en limite d’usage).
En d’autres termes :
Tester la fonctionnalité implicite en production demande une bonne dose d’ingéniosité et d’imagination. C’est la partie véritablement créative des stratégies de test en production.
Tester la fonctionnalité implicite dans les environnements de production nécessite un certain sens de la malice pour s’y perfectionner, et malheureusement, cela ne s’enseigne pas via les processus QA standards.
Aucune méthodologie agile ni framework d’automatisation ne vous apprendra à tester efficacement la fonctionnalité implicite en production, mais une bonne conception de test peut l’encourager.
Alors, comment définir une stratégie de conception de tests pour la fonctionnalité implicite dans votre environnement de production ? Heureusement, c’est possible. Mais avant de plonger dans cette question, explorons quelques autres distinctions essentielles à des tests en production efficaces.
Test positif vs test négatif
À retenir : Lorsqu’on teste en production, les approches positives comme négatives requièrent des précautions et des attentions particulières qui vont bien au-delà des pratiques QA classiques.
La plupart des professionnels QA comprennent la différence de base entre ces deux types de tests :
- Tests positifs en production : Validation du bon fonctionnement des fonctionnalités dans les environnements réels
- Tests négatifs en production : Tester stratégiquement la réaction de votre système à des entrées inattendues sans perturber les utilisateurs réels
Pourquoi les tests en production sont différents
Bien que ces distinctions soient claires en théorie, tester en production apporte des défis uniques :
- Enjeux plus élevés : Les cas limites touchent de vrais clients et les opérations métiers
- Complexité du monde réel : Les comportements des utilisateurs ne suivent que rarement des schémas prévisibles
- Continuité de l'activité : Les tests ne doivent pas perturber le fonctionnement normal
Au-delà du cahier des charges
Les spécifications ne fournissent que rarement tout ce qui est nécessaire pour tester efficacement en production :
Dépendre excessivement du cahier des charges—qu'il vienne du Product ou de l'Engineering—limite votre réflexion. C'est particulièrement problématique lors des tests en production, où l'usage réel diffère souvent des spécifications.
Cela illustre ce que j'appelle « le biais empirique » : attendre que quelque chose vous indique explicitement quoi faire avant de pouvoir le comprendre.
Une conception de test réussie pour les environnements de production nécessite :
- Une bonne paramétrisation fonctionnelle
- Une réflexion logique sur ce qui est possible
- La prise en compte des interactions tant utilisateurs qu'environnementales
Exemple concret : comportements inattendus
À l'époque du Crétacé du logiciel (c'est-à-dire les années 80), je testais un logiciel de conversion de documents et ai découvert des capacités étonnantes :
Afficher l'image
Exemple classique : Dans WordPerfect, il était possible d'insérer une commande d'espacement de lignes au milieu d'un paragraphe, impactant uniquement les lignes suivantes, et ainsi générer des paragraphes avec deux valeurs d'espacement distinctes.
Équivalents modernes lors des tests en production :
- Combinaisons inattendues d'autorisations utilisateur dans les applications cloud
- Séquences de requêtes API imprévues dans les architectures à microservices
- Conditions de concurrence dans des environnements fortement parallèles
Découvrons à présent les trois paramètres clés qui affineront votre approche des tests en production :
1. Test de portée fonctionnelle
Définition : Identifier comment les utilisateurs peuvent exploiter des fonctionnalités dans des contextes ou de façons jamais imaginés lors de la conception.
Pourquoi c'est essentiel pour les tests
Toutes les contraintes ne sont pas prévues en développement. Dans les environnements de production, cet oubli peut avoir de lourdes conséquences.
Au-delà d'une simple validation
Lors de tests en production, considérez ces limites :
À retenir : Valider une fonctionnalité en production va au-delà de la simple confirmation de son fonctionnement tel que conçu : il s'agit aussi de vérifier qu'elle ne peut pas être utilisée de manière détournée, impactant la stabilité ou la sécurité du système.
2. Test d'interruption de workflow en production
Attention : Cette approche suppose que vous testez déjà les workflows définis en production. Sinon, commencez d'abord par ces fondamentaux !
Au-delà du « happy path »
Pendant les tests en production, explorez les interruptions critiques suivantes du workflow :
✅ Workflows interrompus : Processus démarré mais jamais terminé
✅ Opérations annulées : L'utilisateur annule explicitement le processus en cours
✅ Processus relancés : L'utilisateur tente d'effectuer plusieurs fois la même action
✅ Retour en arrière : L'utilisateur revient à des étapes précédentes avec des entrées différentes
Conseils pour les tests en production
Utilisez des techniques telles que les "feature flags" pour contrôler en toute sécurité l'exposition de ces tests en production.
Applications réelles
Astuce : Ces scénarios sont rarement couverts par le cahier des charges, mais ils reflètent le comportement réel des utilisateurs en production.
3. La notion de séquentialité dans les tests en production
Le défi : Dans les systèmes de production avec plusieurs processus concurrents, la séquence des opérations peut entraîner des défaillances inattendues, difficiles à reproduire en environnement de test.
Deux schémas cruciaux de séquentialité
Conditions contributives antécédentes
Afficher l’image
- Définition : Événements qui doivent survenir avant un processus défaillant
- Caractéristiques : Peuvent n’apparaître qu’après des séquences spécifiques se produisant naturellement sur plusieurs jours
- Exemple en production : Permissions utilisateur modifiées → expiration du cache → API spécifique appelée
Conditions contributives ultérieures
- Définition : Défaillances qui ne deviennent apparentes qu’à travers des interactions ultérieures
- Manifestation : La défaillance reste masquée jusqu’à une opération ultérieure
- Exemple en production : Une corruption de données survient discrètement jusqu’à la génération d’un rapport
Pourquoi est-ce si difficile ?
Définir le périmètre des tests de séquentialité en production requiert :
- Une connaissance approfondie des interactions du système
- La modélisation des transitions d’état pour les processus complexes
- La compréhension des combinaisons d’états prévues et imprévues
« Comme ces doubles valeurs d’interligne dans un même paragraphe, ces états inattendus peuvent semer le chaos dans les environnements de production. »
Outils essentiels pour les tests de séquentialité en production
- Ingénierie du chaos pour introduire délibérément des défaillances contrôlées
- Outils d’observabilité pour tracer les changements d’état à travers les systèmes
- Traçage distribué pour suivre les chemins de requête à travers les microservices
En résumé : Les problèmes de séquentialité représentent une des plus grandes sources de bogues graves dans les systèmes de production modernes. Faites-en une priorité dans votre stratégie de test.
En résumé
Les "feature flags" transforment les tests en production d’une pratique risquée en un processus contrôlé et piloté par les données. En découplant le déploiement de la mise en production et en offrant des capacités de retour immédiat, ils créent un filet de sécurité permettant aux équipes de valider les logiciels dans des conditions réelles sans compromettre l’expérience utilisateur ni la stabilité du système.
Plateformes de gestion de fonctionnalités pour les tests en production
Les plateformes de gestion des fonctionnalités ont transformé les tests en production, auparavant risqués, en un processus contrôlé et systématique. Pourtant, de nombreuses organisations n’exploitent pas ces outils efficacement dans leur stratégie de conception des tests.
L’évolution de la gestion des risques en production
Les approches traditionnelles des tests en production impliquaient des décisions binaires : soit une fonctionnalité était active pour tout le monde, soit pour personne. Les plateformes de gestion de fonctionnalités changent fondamentalement ce paradigme :
- Contrôle granulaire : Tester les fonctionnalités auprès de segments d’utilisateurs spécifiques au lieu de mises en production globales
- Rétablissement instantané : Désactiver rapidement les fonctionnalités problématiques sans déploiement de code ni retour arrière
- Exposition progressive : Augmenter graduellement l’exposition des utilisateurs en fonction des données de performance en temps réel
Au-delà des feature flags basiques
Même si le "feature flag" de base existe depuis des années, les plateformes modernes de gestion de fonctionnalités offrent des capacités essentielles qui transforment les tests en production :
Lorsqu’elles sont correctement intégrées dans votre stratégie de tests, les plateformes de gestion de fonctionnalités permettent :
- Confinement ciblé du risque – Limiter l’exposition des nouvelles fonctionnalités à des segments d’utilisateurs précis
- Validation auprès de vrais utilisateurs – Tester avec des utilisateurs réels plutôt que des données synthétiques
- Rétablissement immédiat – Résoudre les problèmes sans déployer d’urgence ni retour arrière
Intégration avec les outils d’observabilité
La véritable puissance des plateformes de gestion de fonctionnalités se révèle lorsqu’elles sont intégrées à des systèmes d’observabilité et de surveillance :
Approche traditionnelle :
- Détecter les problèmes après le déploiement complet
- Vérification manuelle des résultats de test
- Analyse post-mortem après les incidents
Intégration de la gestion des fonctionnalités :
- Faire la corrélation entre l’activation d’une fonctionnalité et les indicateurs du système
- Surveillance automatique des performances pour chaque indicateur de fonctionnalité
- Vision en temps réel de l’impact des fonctionnalités
Impact réel : transformer les tests en production
Les organisations qui mettent en place des plateformes de gestion des fonctionnalités constatent des bénéfices importants :
- Diminution de la gravité des incidents : « Nous pouvons tester les fonctionnalités en production bien avant une campagne marketing. Et si une fonctionnalité pose problème le jour du lancement, il suffit de la désactiver grâce à un kill switch — pas besoin de rollback. » — Chris Guidry, VP Engineering, O'Reilly Media.
- Cycles de sortie accélérés : Les équipes d’IBM, TrueCar et d’autres grandes entreprises exploitent la gestion des fonctionnalités pour tester en production, bénéficiant de ce qu’elles appellent des « déploiements sûrs et sans cérémonial ».
- Couverture de tests élargie : Les indicateurs de fonctionnalité exposent des cas limites impossibles à simuler dans des environnements contrôlés.
Mise en œuvre pratique dans la conception des tests
Pour intégrer efficacement les plateformes de gestion des fonctionnalités dans votre stratégie de conception de tests :
- Concevoir des points de vérification qui s’alignent sur les transitions des indicateurs de fonctionnalité
- Créer des scénarios de repli pour chaque composant associé à un indicateur
- Définir des seuils de performance qui déclenchent la désactivation automatique de la fonctionnalité
- Définir des cas de test spécifiques à chaque segment afin de valider le comportement auprès de différentes populations d’utilisateurs
- Documenter les dépendances entre indicateurs pour éviter les défaillances en cascade
Les plateformes de gestion des fonctionnalités ne remplacent pas une conception rigoureuse des tests — elles la renforcent. La qualité de vos tests en production dépendra toujours avant tout de la pertinence de leur conception.
Pièges courants à éviter
Même avec une gestion des fonctionnalités robuste, plusieurs défis persistent :
- Dette technique liée aux indicateurs – Indicateurs abandonnés ou oubliés créant une dette technique
- Surveillance insuffisante – Manque de corrélation entre l’état du flag et les performances du système
- Excès de confiance – Réduction prématurée des tests avant production
- Interdépendances des indicateurs – Création de relations complexes et difficiles à diagnostiquer
Résumé
Les plateformes de gestion des fonctionnalités offrent de puissantes capacités pour tester en production, mais elles doivent être intégrées avec réflexion dans votre stratégie globale de conception de tests. Les organisations qui en tirent le plus de valeur ne se contentent pas de déployer ces outils — elles repensent fondamentalement la manière de concevoir les tests dans un environnement piloté par les indicateurs de fonctionnalités.
Intégrée intelligemment dans une démarche globale de conception des tests, la gestion des fonctionnalités transforme les tests en production d’un mal nécessaire en véritable avantage concurrentiel.
Outils pour les tests en production : défis de mise en œuvre
Si les indicateurs de fonctionnalité et les plateformes associées constituent la base des tests en production, l’écosystème d’outils plus large présente ses propres défis de mise en œuvre. Le choix et la configuration des bons outils nécessitent une attention particulière aux compétences des équipes, à l’architecture du système et aux besoins de l’organisation.
Outils de monitoring et d’observabilité
Un test en production efficace dépend d’une visibilité complète sur le comportement du système :
- Supervision des performances applicatives (APM)
Bénéfices : Fournit une visibilité précise sur la performance de l’ensemble de la pile applicative.
Défis : Souvent nécessite une instrumentation importante et peut générer un volume excessif de données difficile à gérer pour de petites équipes. - Systèmes de gestion de logs
Bénéfices : Incontournable pour le débogage et l’analyse forensique lors des tests en production.
Défis : Peut générer des volumes de données considérables sans stratégies de filtrage et d’indexation appropriées. - Traçage distribué
Bénéfices : Offre une visibilité de bout en bout dans des architectures microservices.
Défis : Sa mise en place devient beaucoup plus complexe dans des environnements hétérogènes réunissant plusieurs technologies.
Systèmes de gestion des alertes
Un système d’alerte efficace est crucial lors des tests de nouvelles fonctionnalités en production :
- Plateformes d'agrégation d'alertes
Avantages : Consolident les notifications provenant de plusieurs systèmes de surveillance.
Défis : Idéales pour la gestion des incidents mais peuvent être perturbantes si elles ne sont pas soigneusement configurées pour éviter la saturation d'alertes. - Systèmes de réponse aux incidents
Avantages : Rationalisent la communication lors d’incidents en production.
Défis : Nécessitent des guides d’intervention bien définis et des points d’intégration clairs pour être efficaces ; peuvent représenter une surcharge pour des déploiements simples.
Considérations pour la mise en œuvre
Lors de la mise en place d’outils de test en production, les équipes doivent évaluer :
- Besoins en scalabilité – L’outil pourra-t-il gérer vos volumes de trafic et la croissance des données ?
- Capacités d’intégration – À quel point l’outil s’intègre-t-il facilement à votre chaîne d’outils existante ?
- Consommation de ressources – Quelle surcharge l’outil introduit-il lui-même ?
- Expertise de l’équipe – Disposez-vous des compétences nécessaires pour tirer pleinement parti de l’outil ?
- Rapport signal/bruit – Pouvez-vous extraire des informations pertinentes sans être noyé dans les données ?
Pièges fréquents lors de la mise en œuvre
- Prolifération des outils – Accumulation de trop de solutions qui se recoupent
- Instrumentation incomplète – Omission de points de surveillance critiques
- Saturation d’alertes – Génération excessive de notifications que les équipes finissent par ignorer
- Contexte insuffisant – Incapacité à relier les métriques à l’impact sur les utilisateurs
- Silos de données – Création de systèmes de surveillance isolés qui ne partagent pas l’information
Trouver le bon équilibre
Les implémentations de test en production les plus réussies obtiennent un équilibre entre :
- Surveillance complète vs. complexité maîtrisable
- Analyses détaillées vs. surcharge d’information
- Réponses automatisées vs. points de décision humaine
Lorsque vous déployez des outils de test en production, commencez petit avec des objectifs ciblés, puis étendez progressivement la couverture à mesure que votre équipe développe son expertise à la fois sur les outils et dans l’interprétation des données générées.
Charge, complexité, latence
Prenez en compte les facteurs macro du système que sont la charge, la complexité et la latence dans votre conception de test. Ces facteurs peuvent affecter l’exécution ou l’aboutissement d’une requête, d’un processus, ou d’un événement.
L’importance de la charge du système devrait être évidente. La façon dont les requêtes ou transactions sont traitées lors de périodes de forte charge peut entraîner des échecs (à n’importe quelle étape du processus de transaction).
Cela devrait faire partie par défaut de votre planification des tests. Comme nous le savons, la charge peut également être générée par la requête elle-même—c’est-à-dire, une requête de données qui déclenche le traitement et la transmission de vastes volumes d’informations.
La complexité fait ici principalement référence à la complexité des requêtes adressées à un système. Cette complexité peut consister dans le nombre de conditions spécifiées (ainsi que leurs exclusions et exceptions), le nombre de bases de données (virtuelles ou non) sollicitées par les requêtes, ou la topologie de traitement du système lui-même.
Dans le contexte de cette discussion, j’utilise le terme latence pour désigner l’introduction de délais lors du processus de requête, ce qui n’est pas son sens habituel. Je parle ici de latence utilisateur, et non de latence de réponse du système lui-même.
En d’autres termes, comment la fonctionnalité ou capacité se comporte-t-elle si l’utilisateur atteint une étape spécifique du processus puis reste en pause, sans rien faire ? Le système doit-il expirer (ce serait sans doute préférable) ? Doit-il afficher une relance à l’utilisateur ? Doit-il rester dans cet état indéfiniment ?
Les réponses à ces questions peuvent figurer dans les spécifications, mais le produit testé peut ne pas se comporter ainsi, c’est pourquoi il convient justement de tester.
Rôles utilisateur
Bien entendu, les utilisateurs finaux peuvent interagir avec des systèmes logiciels selon différents rôles. Le même utilisateur peut accéder au système sous divers rôles, en fonction de ses actions.
Cependant, les processus et services peuvent aussi avoir différents rôles et privilèges associés. Dans tous les cas, assurez-vous que votre conception des tests et leur planification, qu’ils portent sur des fonctionnalités ou des capacités, prennent en compte et exercent tous les états de rôles possibles.
Et ensuite ?
Vous cherchez plus de conseils sur la conception de tests ? Et souhaitez-vous accélérer la croissance de votre SaaS et développer vos compétences en leadership ?
Abonnez-vous à notre newsletter pour recevoir les dernières analyses de CTOs et de futurs leaders technologiques.
Nous vous aiderons à évoluer plus efficacement et à diriger avec assurance grâce à des guides, des ressources et des stratégies d'experts reconnus !
