¿Qué características son vitales para un buen software de seguimiento de errores?

¿Qué características son vitales para un buen software de seguimiento de errores y por qué son importantes? ¿Qué es, en particular, necesario para que considere que estas características se hacen correctamente?

Sencillez. Si es demasiado complicado o demasiado largo para ingresar u ordenar errores, nadie querrá usarlo.

Integración con SCM, de modo que cualquier solución se pueda rastrear hasta el código, y los cambios en el código se puedan rastrear hasta un problema. Esto requiere vigilancia para registrar solo el código relacionado con el problema que se promueve / verifica. es decir, no "Se agregó la característica xyz, y se corrigieron errores aleatorios en 4 ubicaciones diferentes y un refactorizador rápido de la característica zyx".

Otra buena característica es la gestión del flujo de trabajo, de modo que el proceso empresarial se sigue con el código. Por ejemplo, puede tener una ruta de flujo de trabajo que va más o menos así: Error reportado -> Triaged por prioridad y validez -> asignado a dev -> trabajado en -> asignar a QA -> pasar prueba -> marcar como cerrado.

Propiedad forzada de errores. No debería ser posible tener un problema abierto que no sea responsabilidad de alguien. Aparte de eso, simple es mejor.

• Capacidades de informes buenas / rápidas. La gerencia quiere seguir la tendencia de los errores.

• API para automatización, notificación automática por correo electrónico, integración con control de fuente, etc.

1. informes personalizados : capacidad de crear y guardar rápidamente consultas de tickets, por parte de todos los usuarios, no solo de los administradores. A todos les gusta su propia visión de los errores. Si esto se hace correctamente, no hay necesidad de notificaciones, solo inicie sesión en su vista favorita de 'tickets on my plate'
2. vincular al control de versiones : debería ser fácil encontrar los cambios de código asociados con un ticket.
3. Inteligencia de flujo : el sistema no debe permitir que los tickets se encuentren en estados en los que caerán por las grietas, por lo que si el estado cambia a 'Rechazado', debe exigir la asignación a alguien en desarrollo
4. personalizable : cada proyecto es diferente, cada equipo es diferente. algunos equipos necesitan 8 estados diferentes, algunos solo necesitan 3. pero, la GUI debe permanecer
5. simple : mantenga los elementos clave del boleto grande, directo y simple. versión, titular, descripción, estado, propietario
6. historia : esto realmente se destaca cuando se hace mal (te estoy mirando, Unfuddle); Por lo tanto, debe señalarse. El historial de cambios en el ticket debe ser visible en un buen registro cronológico.

Me parece bastante importante poder vincular problemas (y especificar un tipo de enlace, por ejemplo, depende de). Además de los sospechosos habituales de la versión en la que se encontró el error, en qué versión pretendemos solucionarlo (para que podamos conducir mapas de carreteras), un campo de estimación es bueno para la planificación ágil / de proyectos.

Lo bueno para mí es votar por el público, la capacidad de notificar a los usuarios sobre los cambios en el problema y tener un sistema bastante flexible para clasificar los problemas.

De hecho, casi todo lo que JIRA admite fuera de la caja :)

Cualquier característica que haga una tarea para el programador. ¿No debería ser realmente parte del IDE? Ahí está la lista de errores. Elija uno para trabajar y se ocuparán de todos los sellos de estado y hora. Los cambios de código están vinculados. Las pruebas requeridas están asociadas. Verifíquelo como fijo, actualice el estado y deje que todos los demás lo sepan.

Posibilidad de identificar similitudes en boletos que ya cerraron.

Podría usarse algoritmos de minería de datos, tal vez.

Consulta de gran alcance
El software de seguimiento de errores debería ayudar a gestionar los proyectos mediante el cumplimiento de un proceso de desarrollo riguroso en cada etapa de la resolución de problemas.