¿Debo registrar un error que descubrí y reparé?

Depende de quién sea la audiencia de un informe de error.

Si los desarrolladores solo lo analizan internamente, para saber qué debe arreglarse, no se preocupen. Es solo ruido en ese punto.

Lista no exhaustiva de razones para iniciar sesión de todos modos:

• Las notas de la versión incluyen información sobre errores corregidos (hasta cierto umbral que cumple este error), especialmente si hay una vulnerabilidad expuesta por este error
• La administración desea una noción de "Tiempo empleado en corregir errores" / "Recuento de errores detectados", etc.
• Los clientes pueden ver el estado actual del bugtracker (para ver si se conoce su problema, etc.)
• Los evaluadores obtienen información sobre un cambio que deberían probar.

Diría que depende de si su producto fue lanzado con el error o no.

Si se publicó con el error que encontró, entonces sí, cree un informe de error. Los ciclos de publicación a menudo pueden ser largos y no desea que su error se informe como un nuevo problema mientras ya lo haya solucionado.

Si tu error no se ha enviado todavía, entonces no seguiría el mismo camino. Ahora tendrás personas que intentarán recrear tu error, pero no pueden hacerlo porque aún no se encuentra en una versión, esencialmente perdiendo el tiempo.

Debería hacer esto si se trata de un error que podría haber sido informado por un cliente. El peor de los casos: Usted arregla el error, pero nadie lo sabe. El cliente reporta el error. Su colega intenta solucionar el error, pero no puede reproducirlo en absoluto (porque ya lo ha solucionado). Es por eso que quieres un registro del error.

También es útil si realiza revisiones de código, donde normalmente el código se escribiría para alguna tarea y luego se revisaría. Es mejor en ese caso tener esa solución de error aislada, lo que puede requerir poner algo en su lista de tareas y luego hacer todo el trabajo.

Esto depende de varios factores.

Tanto Pieter B como Caleth enumeran algunos en sus respuestas:

• ¿El error ha sido parte de un lanzamiento oficial?
• ¿Se rastrea específicamente la cantidad de errores / tiempo invertido en ellos?

También puede haber procedimientos internos a seguir, a menudo respaldados por los requisitos de una certificación. Para ciertos certificados, es obligatorio que cada cambio en el código sea rastreable a un registro en un rastreador de problemas.

Además, a veces incluso las correcciones de errores de apariencia trivial no son tan triviales e inocentes como parecen por primera vez. Si agrupas silenciosamente una corrección de errores de este tipo para la entrega de un problema no relacionado, y la corrección de errores más tarde resulta ser problemática, esto hará que sea mucho más difícil localizarlo, y mucho menos aislarlo o revertirlo.

Esta pregunta solo puede ser respondida realmente por su jefe de proyecto, o quien esté a cargo del "proceso de emisión de boletos".

Pero permítame preguntar de otra manera: ¿por qué no registra un error que ha solucionado?

La única razón razonable que veo es que el esfuerzo por archivar el informe de error, cometerlo y cerrarlo, es un orden de magnitud mayor que el tiempo para solucionarlo.

En este caso, el problema no es que el error sea tan fácil de solucionar, sino que el papeleo demore demasiado. Realmente no debería. Para mí, la sobrecarga para crear un boleto de Jira es presionar c , luego ingresar un breve resumen de 1 línea y presionar Enter . La descripción no es una sobrecarga, ya que puedo cortar y pegar eso en el mensaje de confirmación, junto con el número del problema. Al final, . c <Enter> y el problema está cerrado. Eso se reduce a 5 pulsaciones de teclas por encima.

No sé sobre ti, pero eso es lo suficientemente pequeño como para convertirlo en una política, incluso en proyectos pequeños, para registrar cada corrección de errores de esta manera.

El beneficio es obvio: hay bastantes personas que pueden trabajar fácilmente con un sistema de tickets como Jira, pero no con el código fuente; También hay informes generados desde el sistema de tickets, pero no desde la fuente. Definitivamente desea que sus correcciones de errores estén allí, para aprender sobre posibles desarrollos, como una afluencia cada vez mayor de pequeñas correcciones de errores de 1 línea, que podrían proporcionarle una idea de los problemas del proceso o lo que sea. Por ejemplo, ¿por qué tienes que hacer correcciones de errores tan pequeñas a menudo (suponiendo que suceden a menudo)? ¿Puede ser que tus pruebas no sean lo suficientemente buenas? ¿Fue la corrección de errores un cambio de dominio, o un error de código? Etc.

La regla que sigo es que si la sección en la que estás trabajando nunca se ha publicado y aún no se ha ejecutado y ningún usuario la ha visto, corrige cada pequeño error que veas rápidamente y sigue adelante. Una vez que el software ha sido lanzado y está en producción y algunos usuarios lo han visto, cada error que ve recibe un informe de errores y se revisa.

Descubrí que lo que creo que es un error es una característica para otra persona. Al corregir errores sin tenerlos revisados, es posible que esté creando un error en lugar de corregirlo. Coloque en el informe de errores las líneas que cambiaría para corregir el error y su plan sobre cómo debería solucionarse.

En resumen: Si este módulo nunca ha estado en producción, corrija cada error que vea rápidamente y siga las especificaciones. Si el módulo ya está en producción, informe cada error como un informe de error que se revisará antes de solucionarlo.

Sí .

Ya hay algunas respuestas que exponen situaciones en las que vale la pena crear un informe de error. Algunas respuestas. Y difieren.

La única respuesta es que nadie sabe. Diferentes personas, en diferentes momentos , tendrán diferentes opiniones al respecto.

Así que ahora, cuando encuentra un error, tiene dos soluciones:

• piense si vale la pena abrir un informe de error, o no, tal vez pregunte la opinión de un colega ... y luego, en algunos casos, lamente no haberlo hecho porque alguien está preguntando al respecto y si tuvo el informe ya puedes simplemente señalarlos a eso
• acaba de crear el informe

La creación del informe es más rápida y, si no lo es, automatícela.

¿Cómo automatizarlo? Suponiendo que su rastreador admite scripts, simplemente cree un script al que pueda llamar y que usará el mensaje de confirmación (título y cuerpo) para enviar un informe de error y cerrarlo como "implementado" de inmediato, con la revisión de confirmación asociada para el seguimiento.

Voy a aceptar las otras respuestas, todas ofrecen buenas reglas generales e incluso algunas tocan este punto, sin embargo, creo que solo hay una respuesta realmente segura aquí.

Solo pregúntale a tu administrador . Bueno, su gerente o, alternativamente, proyecte un líder o un scrum master, etc., según la estructura de su grupo.

Hay muchos sistemas diferentes de buenas y malas prácticas, pero la única forma de saber que estás haciendo lo correcto para tu equipo es preguntar.

Algo parecido a una conversación de corredor de un minuto haría: "Oye (jefe), si soluciono un error menor que solo toma unos minutos, ¿vale la pena hacer un boleto para él o debo mencionar? ¿Está en mi mensaje de confirmación? " y lo sabrás con seguridad. Todas las buenas prácticas en el mundo son inútiles si ese método molesta a su equipo y a su gerente.