project management - proyectos - Buenas prácticas de seguimiento de errores

software de gestion de proyectos gratis (10)

En mi compañía, estas reglas se aplican:

Solo los verificadores pueden crear problemas.
Los desarrolladores deben enviar un comprobante por correo electrónico para que creen un problema.
Los desarrolladores envían un correo electrónico al jefe técnico para que él se asigne un problema a sí mismos por cuestiones que creen que pueden resolver.
Un desarrollador no puede asignar un problema a otro desarrollador (debe enviar un correo electrónico al cliente potencial).
Si el problema de un desarrollador está bloqueado por otro código de desarrollador, debe resolver este problema fuera del sistema de seguimiento de errores.
Solo los verificadores pueden cerrar problemas abiertos por ellos mismos.
Todas las asignaciones deben ir a través de plomo técnico para que pueda rastrear problemas.
Los errores que no están directamente relacionados con la interfaz de usuario no se ingresan en el sistema (se deben resolver externamente).

¿Qué flujo de seguimiento de fallas estás usando? ¿Funciona bien para ti?

Creo que los clientes también deberían poder crear problemas, sin separación entre los informes de errores y las solicitudes de características.

La asignación de problemas no debe ser realizada por los propios desarrolladores: la decisión de los problemas que deben solucionarse para la próxima versión debe ser responsabilidad del cliente y del gerente.

Otras prácticas se pueden encontrar en Painless Bug Tracking de Joel Spolsky.

Espera, escribes:

Si el problema de un desarrollador está bloqueado por otro código de desarrollador, debe resolver este problema fuera del sistema de seguimiento de errores.

entonces hay errores que quedan fuera del flujo de errores normal. Entonces tiene un segundo sistema para rastrear esos errores, ¿o son todos ad-hoc?

Parece que su sistema de seguimiento de errores es realmente un sistema de seguimiento de defectos de usuario.

¿Funciona bien para ti o estás buscando alternativas?

He utilizado varios tipos diferentes de sistemas de seguimiento de errores en los últimos 10 años, incluyendo nada, un documento de Word, FogBugz, Bugzilla y Remedy. FogBugz es de lejos el mejor. En ese trabajo, a cualquiera se le permitía ingresar errores, y cualquiera podía asignarle un error a alguien más. Descubrí que esto funcionó bien, especialmente si encontré un pequeño error en mi código. En lugar de pasar una hora escribiendo correos electrónicos y rellenando formularios y haciendo que otras personas se involucren, pude registrar rápidamente que encontré y solucioné un error. Esto me animó a ingresar todos los errores que encontré y solucionarlos rápidamente. Si un error requería mucho trabajo, se lo asignaba a mi administrador para que pudiera priorizarlo con mi otro trabajo.
En el trabajo donde utilicé Bugzilla, cada vez que se creaba, asignaba o cambiaba un error, se enviaba un correo electrónico a todos los desarrolladores y gerentes. Esto tuvo el efecto opuesto, me desanimó de encontrar y entrar errores en el sistema.

Mi pequeña tienda utiliza un flujo de trabajo bastante simple:

Cualquiera puede crear un problema (creo que es innecesariamente restrictivo no permitir esto) Esto incluye a los clientes y usuarios de nuestros proyectos de código abierto.
Un panel de control de cambios (suena elegante, pero solo es QA lead y jefe de ingeniería, además de gerente de producto) revisa nuevos problemas y asigna la versión de reparación y la prioridad
Cualquiera puede reasignar un error, hacer una pregunta al periodista o pasarlo a otra persona para arreglar o probar
Cualquiera puede marcar un error resuelto
Solo QA puede cerrar un error; hacemos esto para exigir la verificación de cada corrección de error.

De esta manera, todo se registra en el sistema de seguimiento de errores y mantenemos las cosas más eficientes al no restringir las actualizaciones. Puede terminar con un poco de "spam de errores" de esta manera, pero es mejor que crear cuellos de botella en mi experiencia.

Usamos JIRA como nuestro rastreador de errores: es posible configurar todo tipo de flujos de trabajo personalizados en JIRA para hacer cumplir su proceso particular, pero nunca he encontrado la necesidad de hacerlo en organizaciones más pequeñas.

Suena bastante complicado. Estamos utilizando aproximadamente el siguiente proceso:

Todos en la empresa pueden abrir un ticket de problema y lo asignan a un departamento.
Cada departamento tiene un "despachador" que verifica la validez de las entradas y las prioriza.
Dependiendo de las prácticas del departamento, el despachador le asigna a los desarrolladores boletos para el ciclo de desarrollo actual o se asignan primero los boletos, prioridad más alta primero.
Cuando se resuelve un ticket, vuelve a quien lo abrió. Esta persona también realiza todas las actividades necesarias después, como informar a los clientes.
Todos los boletos se guardan en un sistema de software que facilita estas tareas. Si obtiene un boleto, también recibe una notificación por correo electrónico.

Este es un proceso liviano que alienta a los desarrolladores a asumir la responsabilidad de sus problemas.

Aparte de esto, tenemos varias medidas de aseguramiento de la calidad para el proceso de cambio de cualquier cosa en el software, independientemente de la fuente y el tipo de las solicitudes de cambio. Esto incluye especialmente:

Se debe revisar todo el código antes de verificarlo en el sistema de administración del código fuente. Esto incluye GUI y revisiones de bases de datos por parte de revisores especializados si es necesario
El código debe ser probado minuciosamente por el desarrollador antes de registrarlo.
Después de la compilación mensual, todos los cambios deben probarse nuevamente para evitar problemas que ocurren debido a varios cambios que afectan el mismo código.
La compilación mensual entra en una "primera fase de cliente" en la que solo se implementa en algunos sistemas de clientes. Si esta fase no muestra errores no detectados previamente, la construcción se declara segura.

Usamos BugZilla para el seguimiento de errores y existen reglas como:

Cualquiera puede informar un error y cada pequeño cambio que sea debe pasar a través del sistema de seguimiento de errores. Si se trata de una mejora en el producto, el error se debe marcar como mejora y se debe seguir el sistema de seguimiento de errores.
Cualquiera puede asignar un error a alguien más, lo que significa que es fácil enrutar un problema a otros si un error reside en el código de otra persona. Puede haber circunstancias en las que un error deba solucionarse en más de un lugar, es decir, hay una dependencia en el código de otra persona para ser corregido primero y luego esa otra persona corregirá su código. En esos casos, se asigna un error a la persona que necesita hacer el trabajo primero y luego redirige el error a la persona adecuada reasignándolo.
Si aparece un problema en más de un lugar y el código detrás es diferente, pero aparentemente el problema es el mismo, el error se clona para que se pueda mantener una pista separada de todos los cambios.
Los clientes potenciales técnicos son responsables de priorizar los errores en función de la demanda de ese arreglo en particular.
Los probadores / QAEs son responsables de asignar una Severidad al error, es decir, Crítico / Mayor / Menor, etc.
Todos los errores pasan por el sistema de seguimiento de errores. Los errores que provienen de los clientes se clasifican por separado mediante una bandera personalizada para indicar una falla del cliente. Los errores de los clientes se encuentran principalmente en las compilaciones publicadas más antiguas y se crean parches para ellos, por lo tanto, se mantienen separados.

De esta forma, nos aseguramos de realizar un seguimiento de todos los cambios de forma simultánea en nuestro Source Control System (que es TFS por cierto) y Bugzilla para que cualquier cambio pueda rastrearse hasta el cambio de código / propietario original si es necesario en el futuro.

el registro de errores se trata de velocidad, solo la cantidad mínima de información necesaria para investigar / replicar el error

para proyectos web, esto se reduce a: 1) un título de error descriptivo, 2) la página donde ocurrió el error, 3) una descripción del problema + una captura de pantalla O instrucciones paso a paso para replicar el problema (si una captura de pantalla) no se proporciona)

las capturas de pantalla son muy potentes por dos razones: 1) una imagen vale más que mil palabras, 2) otorga credibilidad al informe de fallos (¿alguna vez investigas un error que no pudiste replicar y piensas que "parece que el cliente está inventando cosas otra vez"?)

Tengo un artículo de blog que profundiza en el tema: Registro de errores como un profesional

He usado una gran cantidad de sistemas de seguimiento de problemas, incluidos jejenes (ugh!), Bugzilla (un poco menos ugh), Trac, Jira y ahora FogBugz. Me gusta Trac sobre todo, pero eso es probablemente porque no soy el administrador en FogBugz y está siendo triste y horriblemente mal utilizado en su encarnación actual.

Obtener el flujo de trabajo correcto es bastante crucial, y curiosamente comienza con la decisión de qué poner en tu rastreador de errores y cómo etiquetar las cosas que colocas allí. Tan pronto como tenga un cliente, todos los equipos de desarrollo realmente rastrean tres tipos de problemas:

Problemas detectados por clientes reales (errores en vivo).
Problemas con el nuevo software actualmente en desarrollo (errores dev).
Cosas que queremos hacer en el futuro (características).

Cada una de estas tres clases de problemas tiene sus propias prioridades, por supuesto. Un ''error en vivo'' que es solo un error de ortografía en un botón puede ser mucho menos importante que un ''error de desarrollo'' que está bloqueando un lanzamiento anunciado públicamente, o que bloquea otro desarrollo, prueba, etc.

La gravedad de un problema describe cuán horrible es el lado que afecta. En mi experiencia, esto se reduce a:

El programa está arruinando algo. Datos, clientes facturados incorrectamente, medicina incorrecta que se dispensa. Esto es tan malo como se pone. Una vez trabajé en un sistema en el que un comando de software retraía un brazo hidráulico justo en el medio de un técnico. Esto es tan malo como se pone.
El programa está fallando y no tenemos una solución alternativa, pero no está arruinando nada (aparte de estar abajo) mientras tanto. Si el tiempo de inactividad resulta en algo que se arruine, use la gravedad n. ° 1.
El programa se está portando mal, pero tenemos una solución alternativa identificada que realmente se puede usar.
El programa se está portando mal de maneras que son molestas pero que no afectan los resultados.
El programa debe ser mejor de alguna manera bien definida: más fácil de usar, implementar una nueva función, ejecutar más rápido, etc.

Otro problema que surge mucho en estos sistemas es el concepto de ''roles''. Según se aplica a los sistemas de seguimiento de problemas, los roles se reducen a quién tiene permitido hacer cosas. ¿Quién puede crear problemas? Quién puede cambiar el estado, quién puede reasignarlos a otro usuario, quién puede cerrarlos, etc.

En los equipos pequeños y medianos con los que he trabajado estrechamente, este conjunto general de reglas ha funcionado bien:

Cualquiera puede crear un problema. El creador puede asignar el problema a cualquiera (o la mayoría) de los destinatarios a medida que se crea. El destinatario predeterminado es el equipo de evaluación de problemas. Los desarrolladores pueden notar los errores que han encontrado trabajando en el código de esta manera, y asignar el error a ellos mismos, para rastrear por qué están cambiando el código.
El equipo Triage se reúne (especifique el intervalo aquí) para evaluar y asignar problemas. El equipo de Triage busca específicamente informes duplicados, en cuyo caso el nuevo problema se ''enrolla'' en la cadena de problemas existente; para temas no producidos desde el campo, que están asignados a QA para la reproducción; y para problemas de alta gravedad de los clientes.
El originador de un error es la ÚNICA persona que puede cerrarlo. Los informes de errores iniciados por QA o por un CSR no pueden ser cerrados por un desarrollador. Sí, esto significa que los errores en los que CS y el equipo de desarrollo no están de acuerdo permanecen sin resolver. ¿Por qué el rastreador de problemas informa un problema como resuelto cuando las personas no están de acuerdo? Si quieres un repositorio digital de mentiras, tienes C-SPAN.

Algunos equipos pueden querer reservar el traslado de un problema de un departamento a otro a los gerentes, otros equipos pueden permitirle a cualquier miembro del equipo mover un problema a (o VOLVER a) otro equipo. Esto puede reducirse a la sospecha de la gerencia, o simplemente a quién se le permite asignar el tiempo de trabajo.

El proceso de Triaje es la clave. El equipo de Triage es esencialmente el que en su organización decide quién trabaja en qué y en qué se trabaja a continuación. El hecho de que el equipo se reúna en un horario regular ayuda a garantizar que no se pierdan las cosas realmente importantes, y que las cosas mundanas no se eliminen debido a la falta de atención. Si no hay nada en la cola Triage, la reunión (concall, netmeeting, cualquiera que sea la implementación) puede ser cancelada por el líder de la reunión.

Si está utilizando Scrum, el equipo de Triage probablemente sea el experto en scrum, y decida si se va a incluir un problema en el sprint actual y asignando correctamente la prioridad si entra en el backlog.

¿Qué flujo de seguimiento de fallas estás usando?

Tester publicará todos los errores en condición abierta
Asignación al desarrollador
El desarrollador intentará arreglar el error - arreglado
Error Cerrado
Reabrir el estado de error