Cómo manejar errores que creo que solucioné, pero no estoy del todo seguro

13

Hay algunos tipos de errores que son muy difíciles de reproducir, que ocurren muy raramente y aparentemente por azar. Puede suceder, si encuentro una posible causa, la reparo, pruebo el programa y no puedo reproducir el error. Sin embargo, como era imposible reproducir de forma confiable el error y sucedió tan raramente, ¿cómo puedo indicarlo en un rastreador de errores? ¿Cuál es la forma común de hacerlo?

Si configuro status como fijo y solution como fijo, significaría algo completamente arreglado, ¿no?

Es una práctica común establecer status en fijo y solution en abrir, para indicar a los evaluadores, que "probablemente está arreglado, pero necesita más atención para asegurarse "?

Editar: la mayoría de los rastreadores de errores (si no todos) tienen dos propiedades para el estado de un error, tal vez los nombres no sean los mismos. Por status me refiero a nuevo, asignado, fijo, cerrado, etc. , y por solution quiero decir abierto ( Nuevo), fijo, no resuelto, no reproducible, duplicado, no es un error , etc.

    
pregunta vsz 26.04.2012 - 08:31

4 respuestas

8
  

¿Es una práctica común establecer el estado en fijo y la solución para abrir, para indicar a los evaluadores, que "es probable que esté solucionado, pero necesita más atención para asegurarse"?

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

indica a los evaluadores que "probablemente está arreglado, pero necesita más atención para asegurarse"

Nota al margen, incluso si rastreador de errores no tiene un campo como el que describe como 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 ser reemplazado por uno que sí lo haga. La capacidad de agregar aclaraciones de forma libre es una característica de importancia crítica ya que los problemas varían demasiado para adaptarse a alguna forma predefinida.

    
respondido por el gnat 26.04.2012 - 08:54
6

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

    
respondido por el eminemence 26.04.2012 - 08:37
3
  

Hay tipos de errores que son muy difíciles de reproducir, que ocurren muy raramente y aparentemente por azar. Puede suceder, si encuentro una posible causa, la reparo, pruebo el programa y no puedo reproducir el error.

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

Por ejemplo, supongamos que cambia el programa, y un probador invierte 1 hora en tratar de reproducir el error, y el error no aparece: ¿fue una hora suficiente? ¿O es una prueba adicional una pérdida de tiempo porque el error ya se ha solucionado?

Por otra parte, cuando no cambias 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?

Dijo que, puedes pensar en cómo modelar ese proceso en tu sistema de seguimiento de errores: no intentar repararlo y entregarlo a los evaluadores puede ser un estado de error como "abrir". Si los probadores 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, corregirlo y establecer el estado en "fijo". Trate de evitar meterse en algo como "no sé si está arreglado".

    
respondido por el Doc Brown 26.04.2012 - 11:18
0

A veces, la única evidencia que tienes es puramente estadística, por ejemplo. ocurre una o dos veces al mes, pero por lo demás parece no estar conectado a nada. Estos son, en general, el peor tipo de error para diagnosticar y resolver que he encontrado, porque no se puede saber si sus correcciones 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 el que comenzamos. La pieza final nunca se encontró, o tal vez lo fue, pero nadie tenía forma de saberlo.

Los dos consejos que tengo son (1) suponen que varias causas podrían estar vigentes hasta que sepa lo contrario, y (2) formulen una hipótesis sobre cómo podrían existir los síntomas, luego desgarre cada línea de la lógica que esté involucrada de manera remota. Los recorridos profundos a veces son el único medio para un final satisfactorio.

    
respondido por el Chris Cochran 17.10.2012 - 20:17

Lea otras preguntas en las etiquetas