Cómo cerrar un error que ya no es relevante

Actualmente estoy en un equipo mediano de desarrolladores web. Estamos usando jira para el seguimiento de errores.

Estamos trabajando en un producto con frecuentes cambios de diseño. Muchas veces se archivan errores sobre un error en el diseño en algún navegador. A veces, cuando llegamos a tratar con un error de baja prioridad, el diseño ya ha cambiado y ya no es relevante.

• ¿Cómo deberíamos cerrarlo?
  Lo que quiero decir es cómo debemos tratar estos problemas. Si bien Jira es el software de seguimiento de errores que utilizamos, estoy más interesado en cómo manejar este tipo de problemas en general.
• ¿Incluso importa? (Nosotros podríamos volver a la disposición más tarde, pero es muy poco probable)

Los matices como ese son importantes si considera el rastreador de problemas como un medio para comunicar el estado de los problemas que se informaron en el proyecto. Para ese propósito, tiene sentido invertir algo de esfuerzo para garantizar que el informe de errores sea fácil de leer y comprender.

Esta situación se vuelve mucho menos confusa si la miras desde la perspectiva de un probador. Si su equipo no tiene un probador, imagine uno (o mejor aún, contrate uno ^{1 , 2 , 3} ).

De acuerdo, entonces hubo un error, el probador puede reproducirlo usando versiones anteriores de su aplicación (nota al margen en el caso improbable de que no conserve copias de versiones anteriores, entonces tiene problemas mucho más difíciles en su equipo que errores obsoletos). El probador puede verlo y puede decir qué está mal, qué es lo que lo convierte en un error.

Ahora dice: "el diseño ya ha cambiado y ya no es relevante": el alto perfil ya no es relevante convierte la mente del probador en una declaración mucho más simple: el problema se ha ido .

• Es importante señalar aquí que el probador profesional debe sentirse cómodo pensando en el sistema como una caja negra . Desde esa perspectiva, no importa mucho cómo sucedió exactamente ese problema, podría ser un cambio de diseño o magia negra o un rediseño total, o un cambio de código concreto, lo que sea.

Desde la perspectiva de la caja negra, su situación es bastante simple. Hubo un problema, todavía es reproducible en una versión anterior, ahora afirma que la versión más reciente ya no tiene ese problema. Para un probador, esto se reduce a una afirmación de que el error está solucionado y, respectivamente, a la necesidad de verificar si la afirmación es verdadera.

El probador profesional tomaría su versión anterior, vería cómo está presente el problema, luego tomará una versión más nueva y comprobará si se ha ido o si todavía está allí.

Desde arriba, la forma más precisa de manejar los errores como usted describe, sería cerrarlos como resueltos, arreglados . Por supuesto, no estaría de más si aclaras en los comentarios que la corrección se produjo como un efecto secundario no deseado del cambio de diseño.

Una de las JIRA personalizadas con las que solía trabajar en un proyecto anterior tenía la resolución "Fijo por diseño" para comunicar cambios bastante profundos que tenían muchas consecuencias, algunas intencionales, otras no. Para un caso como el que usted describe, eso también podría considerarse en lugar de simplemente "Fijo", ya que sugiere al lector de tickets que es más un efecto secundario en lugar de un cambio de código intencional.

Resolvemos problemas como 'Obsoleto'. Esta no es una opción de resolución predeterminada en JIRA, pero es bastante fácil de agregar.

JIRA (y estoy seguro de que otros rastreadores de errores) le permite especificar resoluciones personalizadas para que pueda configurar una resolución "Overtaken By Events" o "Irrelavant", o similar para permitirle expresar el cierre como desee

¿Importa? eso depende, para nosotros diría que sí, ya que nuestro cliente está demasiado preocupado por la cantidad de problemas abiertos en nuestro rastreador, por lo que para nosotros es útil poder decir que están cerrados porque ya no son relevantes sin eliminar el problema por completo .

Incluso sin un cliente preocupado por los números de problemas, la eliminación de problemas antiguos que ya no son relevantes es definitivamente útil solo para reducir el desorden en el navegador.

Usamos FogBugz, pero estoy seguro de que lo mismo (o similar) se aplica aquí:

Solo usamos "Resolved (Fixed)" y comentamos en la edición de resolución algo así como "Fixed by case 12345".

FogBugz coincide con "case \ d +" y vincula los dos juntos en Casos relacionados, pero si Jira no lo hace, debería ser simple simplemente agregar un enlace.

Esto es IMO mejor que una variante "demasiado localizada" porque era un error real, y mejor que simplemente "Obsoleto" porque se solucionó, esa característica no se eliminó simplemente.