¿Por qué los sistemas de seguimiento de problemas suelen tener estados distintos de "Abierto" y "Reabierto"?
Los problemas que están abiertos son generalmente la primera aparición de cualquier problema que sea.
Los problemas que se vuelven a abrir son 1) que vuelven a ocurrir y / o 2) no se solucionan correctamente. Puede haber varias razones para eso: una clave a menudo puede estar vinculada a la descripción original del problema para el usuario final.
No creo que ninguna tienda sensata lo use como una medida para juzgar al personal técnico [solo], pero es útil como medida para identificar qué tan efectivas son las respuestas, y también puede significar problemas subyacentes que deben abordarse.
Mi antigua empresa usó esos estados para rastrear cuántas veces su problema fue a "Reabierto" para ver qué tan "malo" era un desarrollador. Pensaron que existe una correlación entre la cantidad de veces que un elemento de trabajo se "reabre" y su valor como programador.
Ya no trabajo allí.
La vida útil de un error es a menudo:
es decir.
Alguien encuentra un error y lo abre en el rastreador. El desarrollador lo soluciona lo mejor que puede con su comprensión del problema. El probador vuelve a probar para verificar que la solución funcionó y vuelve a abrir si puede verificar que no fue así. Si se verifica la solución, el error se cierra.
El otro escenario es que una solución en otro lugar causó una regresión y el error debe ser reparado nuevamente. Por lo tanto, se vuelve a abrir.
fuente
También puede ser para hacer más obvio que el problema necesita más atención o atención más rápida porque continúa siendo un problema después de que se creía que el problema se había resuelto.
fuente
Abierto significa que es un problema nuevo. La reapertura de meanse ti fue un problema que se abrió-> Cerró y luego volvió a abrir.
¿Por qué se abrió de nuevo? Tal vez el desarrollador y el probador pensaron que el problema se solucionó, pero en realidad no se solucionó. O tal vez el problema se solucionó realmente, pero algunos otros cambios posteriores en el código hicieron que el problema volviera a ocurrir. No importa cómo, pero un problema reabierto es una mala señal y, por lo tanto, se clasifica de manera diferente.
fuente
La forma en que lo usamos aquí:
Nueva tarea: creada al comienzo del proyecto para mostrar todo el trabajo que debe hacerse. Está abierto hasta que alguien lo codifica, luego se resuelve. Solo se vuelve a abrir si algo no se implementó, o si la funcionalidad cambió y el desarrollador tiene que regresar y pasar una buena cantidad de tiempo trabajando en ello.
Error / defecto: abierto por alguien en QA u otro desarrollador que verifica el producto en general. Si se le asigna un error, lo arregla y luego lo resuelve y vuelve a las pruebas. Si el control de calidad considera que no se ha solucionado, lo volverá a abrir y adjuntará cualquier otra información que tenga. El ciclo Resuelto / Reabierto puede continuar hasta que QA esté satisfecho de que el error se ha solucionado, luego cierran el ticket.
Entonces, básicamente, usas Reopen para decir que ya se ha examinado un ticket y que alguien ha trabajado en él y lo sintió resuelto, pero ese no fue el caso.
fuente
Es básicamente un tipo de cosa de consistencia: un error (o un problema en general) está "abierto" si se ha creado desde cero. Se "vuelve a abrir" si se ha creado después de que se haya realizado un procesamiento anterior.
Para un desarrollador (o cualquier persona que maneje el problema) no debería haber ninguna diferencia. Se ha generado una emisión y ahora debe procesarse.
Sin embargo, un estado distinto de "reapertura" aún puede ser útil para varios escenarios:
Primero, puede usarse como una forma de rastrear si su proceso de garantía de calidad funciona o no. Si el control de calidad hizo todo bien, nunca se producirá un error después de que se haya solucionado. Por lo tanto, podría decir que la cantidad de veces que un error se ha establecido en el estado "reabrir" es la cantidad de veces que el control de calidad no ha hecho su trabajo correctamente. Esto, por supuesto, implica que hay un buen proceso de control de calidad establecido y que los usuarios participan activamente en el proceso y saben cuándo "abrir" y cuándo "reabrir" un problema.
Otro uso es que, cuando vuelve a ocurrir un error, no necesita plantear otro problema, pero puede agregar la información a un problema ya existente (y, por lo tanto, mantener información importante como el historial de problemas, archivos adicionales que se han cargado, comentarios anteriores y etc.) pero aún así indica "hey, esto volvió a suceder ).
fuente
Una razón principal para rastrear la "reapertura" es que puede darle una indicación de problemas enrutados profundos, en lugar de simples errores y supervisión de detalles. Si un módulo en particular o una pieza de funcionalidad tiene numerosos "reabastecimientos", apunta a una debilidad que debe abordarse. Una gran cantidad de puntos abiertos individuales para el trabajo apresurado y / o la práctica descuidada.
fuente