Cómo manejar los errores que creo que solucioné, pero no estoy completamente seguro

Hay algunos tipos de errores que son muy difíciles de reproducir, ocurren muy raramente y aparentemente al azar. Puede suceder que encuentre una posible causa, la solucione, pruebe el programa y no pueda reproducir el error. Sin embargo, como era imposible reproducir de manera confiable el error y ocurría tan raramente, ¿cómo puedo indicar esto en un rastreador de errores? ¿Cuál es la forma común de hacerlo?

Si configuro el statusa fijo, y el solutionfijo, significaría algo completamente fijo, ¿no?

¿Es una práctica común establecer lo statusfijo y lo solutionabierto para indicar a los evaluadores que "probablemente sea fijo, pero necesita más atención para asegurarse"?

Editar: la mayoría (si no todos) los rastreadores de errores tienen dos propiedades para el estado de un error, tal vez los nombres no son los mismos. Por statusquiero decir nueva, asignado, fijo, cerrado, etc. , y por solutionque quiero decir abierta (nuevo), fija, sin solución, no es reproducible, duplicado, no es un error , etc.

¿Es una práctica común establecer el estado como fijo y la solución para abrir, para indicar a los evaluadores que "probablemente sea fijo, pero necesita más atención para asegurarse"?

Común o no, esto es lo que hay que hacer de todos modos, y usted expuso por qué usted mismo: no importa cómo, es un buen enfoque para

indicar a los evaluadores que "probablemente esté solucionado, pero necesita más atención para asegurarse"

Nota al margen, incluso si el rastreador de errores en particular no tiene un campo como el que usted describe solution, el desarrollador puede al menos agregar un comentario de forma libre que explique anteriormente.

_{... y si el rastreador de errores no permite agregar comentarios al problema, entonces debe reemplazarse por uno que sí lo haga. La capacidad de agregar aclaraciones de forma libre es una característica críticamente importante ya que los problemas varían demasiado para ajustarse a algún formulario predefinido.}

El equipo de prueba decidirá si el problema se ha resuelto y si puede cerrarse. Si hay más regresiones, efectos secundarios de la solución, o si la solución en sí misma no es efectiva en otro escenario, el problema se volverá a abrir. Pero si ha realizado suficientes pruebas de desarrollador, es mejor marcarlo como fijo.

Hay tipos de errores que son muy difíciles de reproducir, ocurren muy raramente y aparentemente al azar. Puede suceder que encuentre una posible causa, la solucione, pruebe el programa y no pueda reproducir el error.

En realidad, si no hay un escenario de prueba reproducible, ni siquiera trataría de solucionarlo de antemano. Si quieres que el probador le preste más atención, dales la oportunidad de crear un escenario reproducible.

Por ejemplo, supongamos que cambia el programa, y ​​un probador invierte 1 hora en intentar reproducir el error, y el error no aparece: ¿fue suficiente una hora? ¿O las pruebas adicionales son una pérdida de tiempo porque el error ya se solucionó?

Por otro lado, cuando no cambia el programa y el error no aparece en 1 hora, lo más probable es que el probador invierta otra hora en probar cosas diferentes. Y cuando el probador invierte un día y ya no puede reproducir el error, ¿realmente vale la pena intentar solucionarlo?

Dicho esto, puede pensar en cómo modela ese proceso en su sistema de seguimiento de errores: no tratar de arreglarlo y entregarlo a los probadores puede ser un estado de error como "abierto". Si los evaluadores no pueden reproducirlo, obviamente es "no reproducible". Con suerte, esto no sucede, encuentran un escenario reproducible, puede encontrar la causa raíz de su error, solucionarlo y establecer el estado en "fijo". Trate de evitar meterse en algo como "no sé si está arreglado".

A veces, la única evidencia que tiene es puramente estadística, por ejemplo, ocurre una o dos veces al mes, pero aparentemente no está relacionada con nada. En general, este es el peor tipo de error para diagnosticar y resolver que he encontrado, porque no se puede saber si sus soluciones tienen algún efecto con certeza. El último de estos que tuve que resolver terminó con una solución estadística: la frecuencia de los síntomas bajó al 10% con la que comenzamos. La pieza final nunca se encontró, o tal vez sí, pero nadie tenía forma de saberlo.

Dos consejos que tengo son: (1) asumir que múltiples causas podrían estar en vigencia hasta que se sepa lo contrario, y (2) plantear la hipótesis de cómo podrían existir los síntomas, luego desgarrar cada línea de lógica que está remotamente involucrada. Los recorridos profundos son a veces el único medio para un fin satisfactorio.