Résumé rapide

Les stratégies de test peuvent échouer même si tout le monde est d’accord avec elles, car la pression du monde réel crée un écart entre ce qui est documenté et ce que font réellement les équipes. Lorsque les délais arrivent, les équipes ignorent les vérifications manuelles, les raccourcis deviennent des habitudes et la stratégie s’érode progressivement.

Une stratégie de test peut être réfléchie, bien documentée et acceptée par toute l’équipe, mais ne pas remplir son rôle. C’est la partie qui surprend les gens. Nous avons tendance à supposer qu’une stratégie qui a échoué est une mauvaise stratégie, alors qu’il s’agit bien plus souvent d’un plan raisonnable qui s’effondre discrètement lorsqu’il correspond au fonctionnement réel de l’équipe. L’échec ne vit pas dans les idées. Il réside dans l’écart entre le document et la réalité quotidienne, et cet écart est là où se situent réellement les problèmes les plus intéressants en matière de qualité logicielle.

Introduction

Une stratégie de test peut être réfléchie, bien documentée et acceptée par toute l’équipe, mais ne pas remplir son rôle. C’est la partie qui surprend les gens. Nous avons tendance à supposer qu’une stratégie qui a échoué est une mauvaise stratégie, alors qu’il s’agit bien plus souvent d’un plan raisonnable qui s’effondre discrètement lorsqu’il correspond au fonctionnement réel de l’équipe. L’échec ne vit pas dans les idées. Il réside dans l’écart entre le document et la réalité quotidienne, et cet écart est là où se situent réellement les problèmes les plus intéressants en matière de qualité logicielle.

La stratégie sur papier n’est pas la stratégie en pratique

Chaque équipe dispose de deux stratégies de test, qu’elle en soit consciente ou non. L’un d’eux est écrit : l’ensemble délibéré de choix sur ce qu’il faut tester, à quelle couche et dans quelle mesure. Et il y a celui qui se produit réellement : la somme de ce que les gens font réellement lorsqu’une échéance approche et qu’une décision doit être prise sur le moment, sans avoir le temps de consulter un document.

Lorsque ces deux stratégies correspondent, tout fonctionne comme prévu. Lorsqu’ils se séparent, l’écrit devient une fiction réconfortante décrivant une équipe qui n’existe pas, tandis que le comportement réel reste incontrôlé et indiscuté.

La plupart des échecs stratégiques sont en réalité dus à cette dérive, et non à un défaut de la pensée originale, et comme la dérive est invisible sur le papier, elle peut durer longtemps avant que quiconque ne s’en aperçoive.

La pression est le point de départ de la dérive

La dérive commence presque toujours sous pression, et elle commence petit. Une stratégie de test logiciel dans un document de génie logiciel peut nécessiter des tests de régression approfondis avant chaque version. Cela tient bien pendant un certain temps, jusqu’au trimestre où la date limite est immuable et où la suite de régression prend deux jours que personne n’a. Ainsi, quelqu’un l’ignore discrètement, expédie la version et rien ne perturbe ce moment particulier.

La stratégie a été frappée pour la première fois, non pas parce qu’elle était erronée, mais parce qu’elle n’a pas survécu au premier véritable conflit avec une échéance commerciale. La dangereuse leçon que l’équipe a assimilée est que sauter à la corde était une bonne chose car il n’y avait aucune punition visible.

Répétez cela plusieurs fois au cours de quelques crises, et le plan écrit et le plan vécu se sont séparés pour de bon, l’équipe étant pleinement convaincue qu’elle suit toujours la stratégie.

Une stratégie que personne ne peut suivre n’est pas vraiment une stratégie

Cela indique la cause fondamentale la plus courante, et ce n’est pas la paresse. De nombreuses stratégies sont écrites pour une équipe idéale avec un temps illimité et une discipline parfaite, et non pour la vraie équipe avec son personnel, ses délais et ses interruptions réels.

Un plan qui suppose tranquillement des efforts que personne n’a déployés sera abandonné dès que la réalité le repoussera, et il sera abandonné en silence plutôt que par une décision honnête, ce qui le rend si corrosif. Personne ne se lève pour dire que la stratégie est abandonnée. Cela érode simplement un raccourci raisonnable à la fois.

Les stratégies les plus efficaces que j’ai vues sont d’une modestie presque embarrassante en comparaison. Ils demandent moins que l’idéal théorique, mais le moins qu’ils demandent se produit réellement à chaque fois, aussi bien lors des bonnes que des mauvaises semaines. Une couverture réelle cohérente bat une couverture ambitieuse qui s’évapore dès que le calendrier se resserre, et elle n’est pas proche.

L’automatisation est ce qui permet à une stratégie de survivre à la pression

L’automatisation est importante pour la stratégie, pas principalement pour la vitesse, même si la vitesse est un effet secondaire intéressant. Le fait est que des contrôles automatisés ont lieu, que quelqu’un soit sous pression ou non, que les délais soient ou non serrés, qu’un ingénieur fatigué à la fin d’une longue semaine se souvienne ou non de les exécuter.

Une étape manuelle dans une stratégie est une étape qui finira par être ignorée lors d’une mauvaise journée, et les mauvais jours sont exactement le moment où vous avez le plus besoin que le chèque se déclenche. Une étape automatisée est réalisée précisément lorsque les humains ne le peuvent pas. Cela donne une règle de conception simple pour transformer une stratégie d’aspiration en quelque chose de réel.

Tout ce qui dans votre plan ne doit absolument pas être ignoré appartient à l’automatisation, car l’automatisation est le seul endroit où cette étape est à l’abri d’une personne stressée qui prend un raccourci par ailleurs raisonnable. Les parties manuelles d’une stratégie devraient être celles que vous pouvez réellement vous permettre de perdre lors de votre pire semaine, car tôt ou tard, vous perdrez exactement ces parties.

Illustration numérique d'un flux de travail de tests fonctionnels logiciels montrant les étapes depuis les exigences de l'utilisateur jusqu'à l'exécution des tests, avec des icônes d'état de réussite et d'échec.

Les types de travail qui résistent à l’automatisation

Il vaut la peine d’être honnête : tout ne peut ou ne doit pas être automatisé, et prétendre le contraire crée son propre échec. Les tests exploratoires, le jugement sur l’utilisabilité et le type d’informations provenant d’un humain examinant une version avec suspicion ne se réduisent pas clairement aux scripts.

L’erreur est de ne pas conserver ce manuel. L’erreur consiste à placer les contrôles critiques et incontournables dans le seau manuel à côté d’eux, où ils partagent le même sort sous pression.

Une stratégie réalisable sépare délibérément les deux. La vérification non négociable et reproductible va à l’automatisation. Le travail d’exploration et de jugement reste humain mais est planifié et protégé, ce n’est donc pas la première chose sacrifiée lorsque le temps presse.

Lorsque les équipes mélangent ces deux catégories, elles perdent simultanément le filet de sécurité automatisable et la vision humaine, généralement au moment même de la sortie qui avait le plus besoin des deux.

Mesurez la stratégie que vous exécutez réellement, pas celle que vous avez écrite

Le dernier élément est l’honnêteté concernant l’écart, et c’est celui que les équipes négligent le plus. Si vous ne regardez que la stratégie écrite, vous ne remarquerez jamais qu’elle a dérivé de la pratique jusqu’à ce que quelque chose se brise dans la production et que l’autopsie révèle qu’une étape que tout le monde pensait être en train de se produire s’était tranquillement arrêtée il y a des mois – quelques signaux simples comblaient cet angle mort à moindre coût.

Les fuites de défauts vers la production vous indiquent si votre couverture réelle est réellement valable, indépendamment de ce que prétend le document. Les tests ignorés, ignorés ou en échec perpétuel vous indiquent exactement où les gens se déplacent autour du plan.

Le temps de détection vous indique si la stratégie détecte les problèmes quand elle le devrait ou longtemps après. Ces chiffres décrivent la stratégie que vous appliquez réellement, qui est la seule qui affecte vos utilisateurs, et ils servent d’avertissement précoce lorsque la stratégie vécue a commencé à s’écarter de la stratégie écrite. Les observer transforme la stratégie d’un document que vous consultez une fois par an en quelque chose que vous pouvez réellement piloter de semaine en semaine.

Où cela me laisse

Pourquoi les stratégies de test échouent même lorsque tout le monde les suit : où cela me laisse.

Une bonne stratégie de test n’est pas celle qui s’appuie sur le document le plus complet ou le plus impressionnant. C’est celui dont la version écrite et la version vécue restent proches, surtout sous la pression qui les sépare.

Écrivez pour l’équipe que vous avez réellement plutôt que pour celle que vous souhaiteriez avoir. Automatisez les parties qui ne doivent jamais être ignorées, car c’est la seule façon de survivre à une dure semaine. Protégez le travail humain fondé sur le jugement au lieu de le sacrifier.

Et mesurez ce qui se passe réellement, afin de détecter la dérive alors qu’il s’agit encore d’une petite correction plutôt que d’un incident de production. Faites tout cela, et la stratégie continue de fonctionner pendant les semaines difficiles, qui sont les seules semaines qui testent si une stratégie était réelle en premier lieu.

Sautez-le, et vous vous retrouvez avec un excellent plan qui décrit une équipe qui n’a jamais été tout à fait vous, échouant discrètement alors que tout le monde croit le suivre.

A lire également