¿Cuáles son las mejores prácticas para el seguimiento de errores?

Cada proyecto tendrá sus propios objetivos para un sistema de seguimiento de errores. Solo tú puedes definir el tuyo, pero asoundmove tiene algunos buenos puntos . Para no volverme demasiado repetitivo, simplemente supondré que leíste esa respuesta y saltas directamente:

1. Asegúrese de que su proceso respalde sus objetivos. Te sorprendería la frecuencia con la que las personas eligen una herramienta o implementan un proceso porque es 'la mejor ', pero al final nadie la valora. No proporciona nada útil a nadie y muere.
2. Empieza pequeño. La gestión eficaz del cambio de procesos lleva tiempo y tendrá más éxito implementando pequeños cambios a lo largo del tiempo que tratando de diseñar el proceso de seguimiento "perfecto" y lanzarlo a su equipo de una sola vez.
3. Considere que su base de datos de seguimiento de errores puede tener usos además de la resolución diaria de defectos. Se puede usar como una herramienta de programación en sí misma, para monitorear cuándo está presionando demasiado al equipo (más defectos) o para ayudar a estimar el trabajo futuro.
4. Si lo va a utilizar para realizar un seguimiento de las tareas, tenga cuidado. Errores comunes que puede cometer al rastrear 'tareas' en un sistema de rastreo de errores:
   • Detalle demasiado fino. Suponiendo que se necesitan 10 o 15 minutos como mínimo para escribir una descripción decente de la tarea, debe preguntarse cuánto tiempo llevará esta tarea. Si es algo que se puede hacer en una hora más o menos, está agregando una gran carga administrativa a cada actividad que realiza.
   • Criterios de salida vagos. Los defectos y las mejoras son "simples" de administrar en un sistema de seguimiento de errores: es fácil saber cuándo ha terminado. Dependiendo de tu proceso, alguien valida/confirma/prueba que el cambio solicitado se realizó satisfactoriamente. Es fácil escribir 'tareas' que no tienen un mecanismo claro para saber si la tarea se realizó de manera correcta, suficiente o completa. Estas tareas se convierten en una carga administrativa.
   • Duplicación de esfuerzos. ¿Está capturando tareas en un sistema de seguimiento de autobuses, pero también las está reportando en informes de estado o como tareas en Gantt/horarios?
5. Todas las solicitudes de cambio, ya sean defectos, mejoras o tareas vinculadas a algún tipo de requisito del cliente (que también pueden capturarse en la misma base de datos) y solicitudes de cambio cerradas, tienen una resolución que explica por qué no se realizará ningún cambio o un enlace a la modificación. artefactos Preferiblemente, estos artefactos modificados se registran en su sistema de control de revisión: código fuente, archivos de compilación e inicialización, pruebas y documentos.

Brian, he estado en tus zapatos. Mi principal recomendación es: "Olvídate de Redmine, por ahora, concéntrate en tu proceso"

Una vez que haya definido un buen proceso para el seguimiento de errores, vuelva a ver si Redmine encaja.

Otras recomendaciones basadas en la experiencia:

• Tenga en cuenta que los incidentes más comunes son (Errores (algunos los llaman defectos) y Mejoras (algunos los llaman características))
• Haga un proceso por defecto y otro proceso por características (Cada proceso necesita un tratamiento diferente)
• Consigue el compromiso de tu equipo
• Obtenga el compromiso de sus clientes (solo para uso interno)
• Tenga un proceso para manejar excepciones, esto será más útil de lo que piensa

Pregúntese qué quiere de su sistema de seguimiento de errores y qué conexiones debe tener con otros sistemas (trazabilidad, capacidad de búsqueda).

¿Son los siguientes puntos relevantes para usted (de ninguna manera una lista exhaustiva)?

• Seguimiento de errores durante la vida útil del proyecto (desarrollar y olvidar)
• Seguimiento de errores durante la vida útil del producto (soporte a largo plazo)
• ¿Simplemente realiza un seguimiento de los errores para corregirlos?
• ¿Hace un seguimiento de los errores para descubrir también cómo mejorar sus procesos (costará más pero debería traer beneficios a más largo plazo)?
• ¿Necesita realizar un seguimiento del tiempo dedicado a la investigación y resolución (para analizar los costos, estoy seguro de que hay otras formas de hacerlo)?
• Una buena práctica es hacer referencia al número de error en los comentarios de control de versiones para la solución.
• Una buena práctica es vincular los informes de errores a casos de prueba relevantes y/o secciones relevantes del documento de diseño al que pertenecen (y a los requisitos comerciales asociados); esto le permite revisar el historial de errores siempre que vaya a cambiarlos. requisitos o elementos de diseño (dicha trazabilidad permite un mejor análisis de riesgos y planificación de requisitos de prueba de cambios futuros).
• Escriba un caso de prueba de no regresión como parte de la resolución de este error.

Como alguien que ha probado y creado software (además de liderar un equipo), estos son algunos de los elementos que más significan para mí en lo que respecta a las mejores prácticas de defectos

• Proceso, ante todo... - Averiguar la metodología de prueba/gestión de defectos ahora mismo. Esto eliminará muchos dolores de cabeza en el futuro para usted y todos los involucrados (por ejemplo, no permitirá que sus desarrolladores cierren los defectos, ¿verdad? ¿Quién estará a cargo de verificar los defectos solucionados?) Observe varias metodologías de prueba y adapte uno a tu medida. Defina los roles y responsabilidades de todos los involucrados en el proceso de calidad del software. Calcule también el ciclo de vida de sus errores. La mayoría de las principales herramientas (Bugzilla, Jira, etc.) tienen un ciclo de vida defectuoso ya incorporado. Algunas de las mejores le permitirán definir el ciclo de vida para que se ajuste a sus necesidades.
• ...ahora analícelo una vez más : todos obtienen el proceso que se merecen, pero no siempre el que querían. Revise todo lo que se le ocurrió en el paso anterior y asegúrese de tener algo que funcione y aborde todas sus necesidades de prueba. Solucione cualquier problema, asegúrese de que funcione ahora y esté atento a todo lo que avanza en caso de que sea necesario ajustar algo.
• ¡Describa claramente el defecto cuando lo encuentre! - Puede que esto no esté en el nivel del proceso, pero es uno de mis motivos favoritos. Asegúrese de que los defectos se describan claramente para que pueda comprender cuáles son ahora y en el futuro cuando alguien necesite revisarlos. Es realmente inquietante volver a un error de más de 6-12 meses y no poder entender cuál era el problema.
• Realice un seguimiento de sus defectos : esto le informará mucho sobre la salud de su software. Vincular defectos a casos de prueba específicos, y más específicamente a áreas funcionales, lo ayudará a determinar dónde deben enfocarse los esfuerzos. Si el 70% de sus defectos provienen de la funcionalidad XYZ , ¿significa que la calidad del código en esta área de la aplicación debe volver a examinarse?

En breve:

• Siga un proceso bien definido, por ejemplo: confirmar/reproducir -> analizar el impacto y decidir la prioridad-> analizar las correcciones -> corregir
• honestidad al realizar el seguimiento (importante para PM): sin cierre prematuro de errores, sin rechazo de "errores sin importancia"
• mantén los errores "pequeños" también (importante ya que al terminar de hacerlo también te robarán tiempo)
• Mire la estadística "crítica, no reparada/iniciada" todos los días (por ejemplo, en el tablero de JIRA).
• función congelar lo suficientemente temprano

+1 a Geo volviéndose a centrar en los procesos.

Es posible que desee realizar búsquedas de metodologías de prueba, control de calidad en el desarrollo de software y variaciones de estos.

Un montón de buenas recomendaciones en este hilo. El mero hecho de que esté migrando al seguimiento de errores (en lugar de usar correo electrónico y pizarras) será un gran paso adelante en su proceso de gestión de calidad.

Lo único que parece faltar en las respuestas hasta ahora es la información de la versión del software. Si está realizando un desarrollo multitransmisión o admite n lanzamientos desde el lanzamiento actual, le será muy útil tener los campos "Encontrado en" y "Fijado en" para que pueda realizar un seguimiento de este tipo de cosas.