Verificar el arreglo y no solo el ticket

Entre el ticket terminado y el fallo corregido hay varios pasos que se saltan con facilidad. El cambio puede estar fusionado y esperar una ventana de despliegue. Puede estar desplegado y cubrir solo la ruta que salió en el informe, dejando una variante igual al lado. Puede que nadie lo haya vuelto a probar. Y aunque esté bien, sin una prueba de regresión el fallo vuelve en la siguiente refactorización sin que nadie lo note.

Por eso el cierre del hallazgo lo decide la evidencia y no el estado del ticket. Abre el laboratorio y lee criterio-de-cierre.txt.

Cruza tickets-hechos.csv con despliegues.txt por el número de solicitud de cambio, y después con reprueba.txt. Una reprueba hecha en preproducción tiene valor: dice que el cambio funciona. Pero los clientes siguen usando la versión de producción hasta que llegue la ventana, y el hallazgo sigue abierto mientras tanto. Lo correcto es dejarlo en un estado intermedio, «corregido, pendiente de despliegue», con la fecha de la ventana.

Un arreglo que corrige la ruta del informe y no su gemela es el caso más común de cierre en falso: las dos versiones de una API suelen tener el mismo código copiado, y el desarrollador corrige donde le señalaron. La reprueba tiene que recorrer las variantes anotadas en el hallazgo, y la nota de Teusacá registra lo que encontró en cada una.

Aplica las cuatro condiciones a los ocho hallazgos. Uno tiene todo menos la prueba de regresión, y eso también lo deja abierto: el equipo la anotó para el siguiente sprint, y el hallazgo se cierra cuando la prueba exista.

Que una reprueba no reproduzca el fallo es una pregunta, no una respuesta. Puede que el arreglo funcione; puede que la ruta se haya movido, que la cuenta de prueba no tenga datos o que se haya probado otra versión. Mira la reprueba de AT-2304 y la nota de su despliegue.