Pourquoi le taux de réussite n'est pas un Release Signal

Qu’est-ce qui est « suffisamment bon pour être expédié » ? signifie en fait – et quiat vos indicateurs actuels  direfaire respecter Vous

Le taux de réussite n'est pas un signal de libération. Voici est ce que nous faisons est. 

C'est jeudi après-midi. Release est prévu pour vendredi matin. 

Vous ouvrez le tableau de bord. Taux de réussite : 94 %. Les tests en échec sont ceux que vous avez déjà vus : intermittents, généralement concluants lors d'une nouvelle exécution. Vous les relancez. Résultat : réussi. Vous vous déconnectez. 

Samedi matin, votre téléphone vibre. 

Des utilisateurs signalent des déconnexions intempestives. L'équipe de développement est en alerte maximale. La cause : une condition de concurrence lors de l'actualisation du jeton d'authentification. Cette même instabilité avait été détectée par un test instable pendant quatre sprints consécutifs, le temps que l'équipe apprenne à relancer le test jusqu'à ce qu'il soit concluant. 

Le signal était là depuis le début. Vous ne le captiez tout simplement pas. 

L'indicateur que tout le monde suit. La question à laquelle il ne peut répondre. 

Le taux de réussite est la mesure la plus courante en assurance qualité mobile. C'est aussi l'une des moins utiles pour prendre des décisions de mise en production. 

Un décompte de 847 réussites et 23 échecs ne renseigne en rien la direction sur les risques. Il ne révèle pas si ces 23 échecs concernent un flux de paiement critique ou une page de paramètres obscure. Il ne montre pas si les échecs sont en augmentation d'une version à l'autre ou s'il s'agit de régressions isolées.1] 

Un taux de réussite de 94 % n'est pas un signal de publication. C'est un simple décompte. Et un décompte sans contexte ne répond pas à la question essentielle avant chaque publication : Où se concentre le risque dans cette configuration ? 

Un échec dans un flux de confirmation de paiement ne présente pas le même risque qu'un échec dans un cas limite rarement utilisé. Mais le taux de réussite les traite de la même manière.2] 

Si cela ne vous dit rien, voici quelques informations qui vous seront utiles. 

Cette histoire d'ouverture n'est qu'une variante d'un schéma qui se répète sous différentes formes dans presque toutes les équipes mobiles. Les détails changent, mais la cause profonde reste la même : le signal était là, mais personne ne disposait d'un système pour le détecter. 

En voici deux autres que vous avez probablement déjà vécues. 

Personne n'a remarqué l'erreur car le chiffre semblait correct. 

Sprint 6. Un test portant sur l'écran de confirmation de paiement commence à échouer. 1 échec sur 847 – taux de réussite de 99.8 %. Il semble s'agir d'un simple bruit de fond. Le produit est déployé. 

Trois jours plus tard, des utilisateurs signalent ne plus recevoir les e-mails de confirmation de commande. Une intégration en aval a dysfonctionné sans avertissement, et le seul test permettant de la détecter a été négligé car les résultats globaux semblaient satisfaisants. 

Le problème n'était pas l'absence d'un test. C'était le fait que le taux de réussite rendait invisible un échec à haut risque en le transformant en un chiffre rassurant.1] 

La lente dérive que personne n'a signalée 

Sur quatre sprints, le taux de réussite passe de 97 % à 96 %, puis à 94 % et enfin à 93 %. Chaque baisse semble correspondre à une variation normale. Aucun seuil, aucune courbe de tendance, aucune alerte : juste un chiffre dans un rapport hebdomadaire que personne ne compare à celui du sprint précédent. 

Lorsque le seuil de 93 % est atteint, on constate 11 nouvelles défaillances récurrentes réparties sur trois domaines fonctionnels. Aucune n'est alarmante prise individuellement. Ensemble, elles signalent une dégradation systémique. 

La version dangereuse de ce phénomène n'est pas une chute brutale. Il s'agit d'une dérive lente qui ne devient visible que lorsqu'on l'analyse sur la durée – et non pas comme une simple photographie.4] 

Qu’ont en commun ces scénarios ? 

Aucun de ces tests n'a échoué. Les tests ont été exécutés. La suite de tests a été exécutée. Les données étaient présentes. 

Ce sont tous des échecs d'interprétation. L'équipe avait le signal, mais aucun système pour le détecter. 

Ce qui se passe ensuite est prévisible : les développeurs cessent de lire attentivement les journaux d’erreurs. Les responsables de l’assurance qualité cessent de trier chaque version défaillante. Les véritables erreurs sont ignorées au même titre que les erreurs mineures. Il ne s’agit pas de négligence, mais d’une réaction rationnelle face à un système qui produit trop de bruit et trop peu d’informations pertinentes. Lorsque chaque erreur se ressemble, les équipes cessent de les examiner de près.3] 

La bonne question avant chaque sortie 

La plupart des discussions avant la sortie d'un produit portent sur la question : « Les tests ont-ils réussi ? » Or, cette question est celle qui permet réellement de prédire la sortie du produit. safety est différent : Où se concentre le risque dans cette configuration ? 

Répondre à cette question nécessite un contexte que le taux de réussite ne fournit pas. 

Localisation des pannes, et pas seulement leur nombre. Une défaillance dans un parcours utilisateur critique est catégoriquement différente d'une défaillance dans un cas limite rarement utilisé. Ce qui compte, c'est la nature des défaillances, leur emplacement et si certaines se situent sur des chemins empruntés par de vrais utilisateurs.2] 

L'évolution dans le temps, et non pas seulement la situation actuelle. Un taux de réussite de 93 % n'a pas la même signification si le dernier sprint était de 97 % que s'il s'est maintenu à 93 % pendant six builds. La stabilité d'un build à l'autre est un indicateur de préparation à la publication bien plus fiable qu'un seul test ponctuel – mais seulement si l'on s'intéresse à la tendance et non pas seulement au chiffre.4] 

L'instabilité est un signal de première classe, et non un bruit à supprimer. Des tests instables érodent la confiance dans l'automatisation. Lorsque les échecs semblent aléatoires, les équipes relancent les pipelines, ignorent les signaux d'alerte et ralentissent les mises en production. Les équipes qui traitent l'instabilité comme des données structurées – en classant les échecs, en analysant les tendances d'instabilité par zone de test et en cherchant à comprendre pourquoi un test alterne – sont celles qui détectent les conditions de concurrence avant qu'elles ne provoquent des incidents en production. 

Identification des défauts avant expédition. Pour prendre une décision de mise en production pertinente, il est nécessaire de savoir non seulement que les tests ont échoué, mais aussi si ces échecs ont une cause profonde claire, s'ils sont nouveaux dans cette version ou récurrents, et s'ils se situent sur un chemin que les utilisateurs réels emprunteront. 

Pourquoi le mobile complique les choses 

Sur mobile, le problème du rapport signal/bruit est plus important que sur le web. 

La fragmentation des appareils, les délais d'examen des boutiques d'applications, les réseaux instables, les limites d'exécution en arrière-plan et les comportements spécifiques au système d'exploitation font que des problèmes de qualité apparaissent souvent en dehors du laboratoire. Un test concluant avant la soumission est utile, mais insuffisant.5] 

Une suite de tests réussie sur vos appareils de laboratoire ne vous renseigne quasiment pas sur l'expérience utilisateur sur des matériels, des systèmes d'exploitation et des réseaux différents. Sans analyse comparative des scénarios de défaillance avec les environnements réellement pertinents, le taux de réussite non seulement masque le risque, mais le déforme. 

Le même test peut réussir sur un appareil et échouer sur un autre avec une configuration identique. La variabilité de l'environnement (état du système d'exploitation, paramètres régionaux, conditions réseau, historique de l'appareil) signifie qu'un code de test identique produit des résultats différents pour des raisons qui n'ont rien à voir avec votre application. Sans visibilité sur ce que faisait l'environnement pendant une exécution, une suite de tests réussie n'est pas une garantie. C'est une supposition qui s'est avérée juste.6] 

Que faut-il exiger de vos analyses de tests ? 

L'objectif n'est pas seulement l'automatisation. Il s'agit d'un déploiement à haute fiabilité, où chaque version passe par des contrôles pertinents, fiables et adaptés à l'utilisation réelle des appareils par les utilisateurs.7] 

Pour y parvenir, il faut traiter les données de test non pas comme un simple registre de réussite/échec, mais comme un problème d'analyse. Cela implique de concevoir – et d'exiger – des outils qui permettent de visualiser la concentration des défaillances, les tendances de stabilité et les schémas d'instabilité dans une vue d'ensemble. avant C'est vous qui décidez d'expédier. 

La plupart des équipes sont à un pas de cet objectif. Les données existent. Les signaux sont dans les journaux. Ce qui manque, c'est une couche d'analyse permettant de transformer les résultats d'exécution en informations exploitables pour la mise en production. 

La prochaine génération d'outils d'analyse de tests doit être construite autour d'une seule question : non pas « comment la suite a-t-elle fonctionné ? » mais « où dois-je m'inquiéter concernant cette version ? » 

At Digital.aiVoilà le problème sur lequel nous travaillons. Nous ne pensons pas que la solution réside dans davantage de tests. Nous pensons plutôt qu'il faut des signaux plus pertinents et la rigueur nécessaire pour se poser une question plus approfondie avant chaque mise en production. 

Digital.ai Tests donne aux équipes mobiles infrastructure d'exécution pour exécuter des tests à grande échelle. couche analytique Transformer ces données en confiance pour la publication, c'est ce que nous développons ensuite.