Cómo evaluar una prueba inestable

Una prueba poco fiable consiste en dos estimaciones. Aún no sabe cuál de las dos es la correcta.

Una de las versiones consiste en una corrección de una sola línea: una suposición sobre la sincronización, una dependencia del orden de las pruebas, un elemento que faltabaawait. La otra versión supone tres días de investigación sobre una condición de carrera en el código de producción que, por casualidad, la prueba logró detectar. Cuando las tarjetas van del 2 al 13, el equipo no discrepa sobre el tamaño. Discrepa sobre qué tipo de error es, que es la verdadera incógnita.

Hacer una estimación para averiguar el alcance de algo, en lugar de hacerlo a posteriori, es lo que hace que esta historia acabe en el puesto 5 en la primera semana y en el 13 en la tercera. La solución no radica en una cifra más precisa, sino en un enfoque diferente del trabajo. Establezca un plazo para la investigación y, una vez se conozca el alcance, realice la estimación de la solución concreta.

Lo que se dice en la sala

Ingeniero A: «Si falla por la razón que yo creo, esto es un 2».

Ingeniero B: «Si falla por la razón que yo creo, es un 13».

Pregunta principal: «¿Alguien lo ha ejecutado realmente de forma local con la semilla fijada?»

Pregunta: «Solo falla en la integración continua. Nunca en un equipo de desarrollo».

Preguntas que conviene plantearse antes de votar

• ¿Se reproduce el error en el entorno local o solo en CI?
• ¿Con qué frecuencia falla: 1 de cada 50, 1 de cada 5, cada dos veces que se ejecuta?
• ¿Cuándo empezó a fallar? ¿En qué commit?
• ¿Es que la prueba da un resultado erróneo o está detectando algo real?
• ¿Hay alguien que lo esté desactivando mientras tanto, y a qué precio?

La diferencia entre el ingeniero A y el ingeniero B no es una discrepancia en cuanto a los puntos de historia que se pueda resolver promediando los valores. Se trata de una incógnita que hay que investigar. Un «spike» breve y limitado la resuelve; una discusión más acalorada, no.

Establezca un plazo, no una solución. Medio día para investigar y, a continuación, un reportaje en toda regla sobre lo que descubra.

Consulte cómo estimar un error sin posibilidad de reproducirlo para un caso similar, y errores habituales en el Planning Poker para estimar errores con precisión a nivel de funcionalidad. Eche un vistazo a los demás ejemplos prácticos de estimación, o inicie una sesión gratuita de Planning Poker cuando la investigación haya dado resultado.