Évaluation d'un test instable

Un test aléatoire correspond à deux estimations. Vous ne savez pas encore laquelle des deux.

Dans un cas, il s’agit d’une correction en une seule ligne : une hypothèse de synchronisation, une dépendance liée à l’ordre d’exécution des tests, un élément manquantawait. Dans l’autre cas, il a fallu trois jours pour identifier une condition de concurrence dans le code de production que le test a justement détectée. Lorsque les cartes vont de 2 à 13, l’équipe n’est pas en désaccord sur la taille. Elle est en désaccord sur le type de bogue dont il s’agit, ce qui constitue la véritable inconnue.

C’est en estimant l’ampleur d’un problème avant de s’y attaquer, plutôt qu’après coup, que cette histoire se retrouve à la 5e place la première semaine et à la 13e la troisième semaine. La solution ne réside pas dans un chiffre plus précis, mais dans une approche différente du travail. Fixez un délai pour l’analyse, puis estimez la solution concrète une fois que la nature du problème est connue.

Ce qui se dit dans la salle

Ingénieur A : « Si le problème est dû à la raison que je suppose, je lui attribue la note de 2. »

Ingénieur B : « Si ça présente des dysfonctionnements pour la raison que je soupçonne, c’est un 13. »

Introduction : « Quelqu’un l’a-t-il déjà exécuté localement avec la graine fixée ? »

QA : « Cela ne plante que dans l’environnement de CI. Jamais sur une machine de développement. »

Questions qu’il convient de se poser avant de voter

• Ce problème se reproduit-il localement ou uniquement dans l’environnement de CI ?
• À quelle fréquence cela échoue-t-il : 1 fois sur 50, 1 fois sur 5, une fois sur deux ?
• Quand cela a-t-il commencé à ne plus fonctionner ? À partir de quel commit ?
• Le test est-il erroné, ou détecte-t-il quelque chose de réel ?
• Y a-t-il quelqu’un qui le désactive en attendant, et à quel prix ?

L’écart entre l’ingénieur A et l’ingénieur B n’est pas un désaccord sur les points de story que l’on peut gommer en faisant la moyenne. Il s’agit d’une inconnue qu’il faut élucider. Un « spike » court et limité permet de le combler ; une discussion plus animée n’y parvient pas.

Fixez-vous un délai, pas un objectif précis. Une demi-journée pour mener l’enquête, puis un véritable article sur ce que vous aurez découvert.

Consultez « Estimer un bug impossible à reproduire » pour un cas similaire, et « Erreurs courantes au Planning Poker » pour estimer des bugs au niveau d’une fonctionnalité. Parcourez les autres « Exemples d’estimations concrètes », ou « Lancez une session gratuite de Planning Poker » lorsque l’analyse aura abouti à un résultat.