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 lo que realmente se desconoce.

Hacer una estimación para averiguar cuál es la magnitud 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 que se conozca el alcance, realice la estimación real de la solución.

Lo que se dice en la sala

Ingeniero A: «Si el problema se debe a lo 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 es errónea 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. Se trata de una incógnita que hay que investigar. Un «spike» breve y limitado la resuelve; una discusión más acalorada, no.

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

Consulte «Cómo estimar un error sin reproducción» para el mismo caso, y «Errores habituales en el Planning Poker a la hora de estimar errores con precisión de característica». 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 arrojado un resultado.