Cómo reproducir un error y qué hacer con los que no se pueden reproducir

“Cannot reproduce” [no se puede reproducir] es la forma más habitual en que muere un informe de error, y merece la pena leer la frase con atención, porque no dice lo que la gente cree que dice. No es una afirmación sobre el error. Es una afirmación sobre dos entornos: el de quien lo reportó, donde sucedió, y el suyo, donde no sucedió.

El error no está en duda. Alguien lo vio ocurrir. Lo que está en duda es si usted puede recrear las condiciones que necesitaba, y la mayoría de las veces el informe no las contiene, porque quien lo escribió no tenía ni idea de cuál de las mil cosas que lo rodeaban era la que importaba.

Lo que una reproducción realmente necesita

Los pasos son solo una de cuatro cosas, y son la única en la que todo el mundo piensa.

Los mismos pasos. Lo que se hizo clic, en orden, empezando por un punto desde el que usted también pueda partir.

El mismo estado. La cuenta, los permisos, los indicadores de funcionalidad, los ajustes que se cambiaron hace dieciocho meses, el borrador a medio terminar que sigue en la base de datos. Esta es la que hace fracasar la mayoría de los intentos, porque el estado es invisible para quien está dentro de él. No sabe que su cuenta es distinta de las demás. Para esa persona es, simplemente, su cuenta.

Los mismos datos. No un registro de prueba recién creado, sino el concreto: el pedido con un reembolso, el nombre con un apóstrofo, la lista que está vacía, el archivo subido de cuarenta megabytes. Los datos de prueba están ordenados. Los datos de producción son quince años de decisiones, que es la misma brecha que hace que el entorno de staging le mienta.

El mismo entorno. Navegador y compilación, dispositivo, red, tamaño de pantalla, reloj, extensiones. Una versión por sí sola puede bastar: “la última versión de Chrome” fueron tres versiones principales distintas en una sola semana.

Cuatro ejes, y un informe normalmente solo fija uno de ellos. El trabajo de reproducir consiste en adivinar los otros tres, por eso lleva toda una tarde y por eso tan a menudo termina en un encogimiento de hombros.

Empiece por el estado, no por los pasos

El instinto es seguir los pasos y ver qué ocurre. El mejor primer movimiento es preguntarse qué tendría que ser cierto para que esos pasos fallaran.

Si el proceso de pago falla en la etapa de cobro, los pasos son tres clics que cualquiera puede dar. Lo que no es universal es la cesta, la dirección, el método de pago, la divisa, si a esa cuenta se le ha hecho alguna vez un reembolso. Averigüe cuál de esos factores podría cambiar el resultado, y habrá convertido un informe vago en tres o cuatro experimentos concretos.

Débil

Siguió los pasos en una cuenta de prueba. Funciona sin problemas. Se cerró como no reproducible.

Mejor

Los pasos funcionan en una cuenta nueva. La cuenta de quien reportó el error tiene guardada una tarjeta en una divisa que dejamos de admitir, y el fallo está en la búsqueda de divisa. Se reprodujo añadiendo una a una cuenta de prueba.

La segunda versión no exige más esfuerzo. Es el mismo esfuerzo dirigido a la pregunta correcta.

Reduzca la reproducción a lo mínimo que siga fallando

Una vez que falla de forma fiable, vaya quitando piezas. Elimine un paso, elimine un campo, use un archivo más pequeño, desactive una extensión, recorte los datos. Cada eliminación o bien mantiene el fallo, en cuyo caso esa pieza no era necesaria, o bien lo detiene, en cuyo caso acaba de encontrar algo que importa.

Merece la pena hacerlo incluso cuando ya tiene la solución, por dos razones. Una reproducción mínima es un caso de prueba que alguien puede conservar. Y el propio acto de reducir muy a menudo encuentra la causa antes de haber mirado el código: el error que solo sobrevive cuando la lista está vacía le está diciendo lo que es.

Esté atento a la reproducción que solo funciona a veces. Eso no es una reproducción fallida, es otra forma de error, y la intermitencia es información, no ruido: algo compite por un recurso, o depende del orden, o de que una caché esté fría. La misma lógica que hace que merezca la pena investigar una prueba inestable en lugar de repetirla se aplica aquí.

Los que no se pueden reproducir por construcción

Algunos fallos no se pueden reconstruir en su máquina, y por mucha insistencia que le ponga eso no cambia. Reconocerlos a tiempo vale más que esforzarse más.

Necesitaba su reloj. Un dispositivo con la hora mal ajustada produce fallos de certificado, sesiones caducadas y marcas de tiempo imposibles. Esas fueron tres de las cinco causas detrás de una advertencia de certificado.

Necesitaba su red. Un proxy corporativo, un filtro de DNS, un portal cautivo, un operador móvil que reescribe las peticiones. Usted no puede unirse a esa red, así que no puede ver qué hace.

Necesitaba su compilación. Un despliegue escalonado puso a una fracción de usuarios en una versión que nadie más tiene, ni siquiera usted.

Necesitaba ese momento concreto. Un despliegue a medias, una caché que estaba fría, un servicio de terceros que iba lento durante noventa segundos. El estado que lo causó dejó de existir antes de que se escribiera el informe.

Necesitaba sus extensiones. Algo inyectado en la página la cambió. Usted tiene otras distintas, así que tiene una página distinta.

Para estos casos la pregunta no es “cómo reproduzco esto” sino “qué era cierto en ese momento, y si todavía puedo averiguarlo”.

Lo cual es un argumento a favor de capturar en vez de reproducir

Cada elemento de esa lista es invisible después de los hechos y barato de registrar en el momento. La consola en el instante en que se rompió. La petición fallida con su estado y su tiempo de respuesta. La compilación del navegador, el tamaño de pantalla, la URL. Nada de esto exige que quien reporta sepa qué importa, que es precisamente la dificultad, porque nunca lo sabe.

Ese es el argumento a favor de un informe que lleve consigo sus propias pruebas en lugar de una descripción de ellas. Reproducir es una forma de recuperar información que se descartó, y resulta cara precisamente porque esa información se descartó.

Volver a preguntarle a quien reportó, pero bien

Cuando de verdad tenga que volver a preguntar, pida las cosas que esa persona pueda responder de verdad, no las que a usted le gustaría que hubiera escrito.

Mal: “indique los pasos exactos para reproducirlo”. Esa persona ya cree que lo hizo.

Mejor, y cada una de estas preguntas tiene una buena tasa de acierto:

• ¿A qué hora ocurrió, y qué hora marca su dispositivo ahora mismo? Dos preguntas, no una. La diferencia entre ambas es un diagnóstico.
• ¿Ha ocurrido más de una vez? Una vez es un instante. Varias veces es un estado.
• ¿Ocurre en una red distinta, por ejemplo con datos móviles en lugar de wifi?
• ¿Qué aparece exactamente en la pantalla? Las palabras, no un resumen de ellas.
• ¿Con quién más puede reproducirlo? Otra cuenta lo acota a los datos; otra persona en la misma cuenta lo acota al dispositivo.

La guía de informes de errores recoge la forma completa de un buen informe, y los errores más comunes cubre lo que suele faltar con más frecuencia.

Qué escribir cuando se rinde

A veces de verdad no se puede, y cerrarlo es la decisión correcta. No lo cierre solo como “no se puede reproducir”, porque esa frase no le dice nada a la siguiente persona y esta acabará dedicándole la misma tarde que dedicó usted.

Escriba lo que probó. Qué cuenta, qué navegador y qué compilación, qué datos, cuál de los cuatro ejes varió y cuál no pudo variar. Entonces, el siguiente informe del mismo problema, de otra persona con otro detalle, no será un punto de partida en blanco. Será el segundo dato, y dos informes que comparten un mismo detalle inusual suelen ser toda la respuesta.

Esa es también la versión honesta del estado. El error no quedó refutado. No se reprodujo con la información disponible, que es una afirmación distinta y mucho más útil de dejar constancia.