¿Deben los desarrolladores introducir errores en el sistema de seguimiento de errores?

Si descubre un error, no se me ocurre ninguna buena razón para no introducirlo en el sistema de seguimiento de errores, ya sea que lo arregle o no. Para eso está el sistema de seguimiento de errores, después de todo.

En algunos casos, podría tener más sentido informarlo a una persona de control de calidad que tenga más experiencia en el manejo del sistema, pero en cualquier caso se debe hacer un seguimiento del error.

Es posible que exista alguna razón, válida o no, por la que los desarrolladores no deberían ingresar errores. Una posible razón podría ser que el sistema de seguimiento de errores sea visible para personas externas, y tener demasiados errores reportados se ve mal. Esa es una muy mala razón, que debe abordarse de alguna otra manera que aún permita el seguimiento de errores. Pregúntale a tu jefe.

(Por supuesto, si hay un error en el código en el que aún estás trabajando y no aparece en nada de lo que se ha publicado, no hay necesidad de rastrearlo en el sistema, aunque hay un comentario de TODO en la fuente. el código puede ser una buena idea. Para tomar un caso extremo, "este código no se compilará porque aún no he escrito el punto y coma al final de esta línea" no es un error notificable.)

En cuanto a por qué otros desarrolladores no ingresan errores, deberás preguntarles. Probablemente deberían.

Debe ingresar los errores en el sistema de seguimiento de errores en ambos casos:

• cuando el error se relaciona directamente con el código en el que está trabajando,

• cuando el error está relacionado con el código en el que no estás trabajando en este momento o con la parte en la que trabaja otro desarrollador.

Esto es esencial, ya que el sistema de seguimiento de errores está hecho para ... monitorear errores. Cada bicho Si descubres que algo está mal, no lo arregles. Documentar a través del sistema de seguimiento de errores. Cuando más tarde, un cliente que ejecuta una versión anterior del software informará un error que es un duplicado exacto, podrá vincularlo a su informe. Si no tiene nada con qué vincular, perderá su tiempo (o su colega) buscando el error en las revisiones anteriores, luego intentará resolverlo y, finalmente, encontrará que el error ya se resolvió por arte de magia.

Esto también explica por qué los freelancers deben usar tanto el control de versiones como el sistema de seguimiento de errores: esas dos herramientas no son solo para equipos.

No hay una razón válida para no ingresar un defecto en el sistema de seguimiento de defectos. Los únicos lugares donde he visto correcciones de errores aplicadas sin seguimiento es porque el proceso se rompió fundamentalmente. Si este es el caso, arregla el proceso.

las razones para no ingresar son:

• El proceso mide y castiga según el informe de defectos: no informar, no ser castigado. En este caso salga de la organización
• El proceso es una carga: requiere demasiado esfuerzo y tiempo para ingresar un defecto y llegar al punto de solucionarlo. El proceso debe cambiarse para permitir a los desarrolladores realizar un seguimiento rápido de un error ligero a través del proceso de clasificación / aceptación / reparación.
• Algunos desarrolladores son perezosos / descuidados / hackers que no les importa el impacto de las cosas que hacen en otros. Reclutar desarrolladores profesionales.
• Soy una banda de un solo hombre, no veo el punto. Ve a trabajar para una banda de 2 hombres y lo harás ...

Arreglar el error de inmediato es probablemente una mala idea. Primero, alguien más podría estar trabajando en la misma solución, dando como resultado un esfuerzo duplicado, y también, dependiendo de la metodología de desarrollo que está siguiendo, priorizar en qué trabajar a continuación (corregir un error o implementar una nueva función) es más de un decisión de gestión luego una decisión de desarrollo.

La decisión no es clara, e implica compensaciones.

(algunos) PROS

El seguimiento de errores es esencial para la comunicación, especialmente en equipos grandes. Uno de los mejores beneficios de tener varios ojos en el código es la capacidad de detectar problemas antes, y ese beneficio se pierde si los errores no se registran o rastrean a medida que se desarrolla.

• A menudo, los errores se resuelven más fácilmente cuando ya estás en una parte del código, trabajando para entenderlo.
• Incluso en equipos más pequeños, hay muchos beneficios que se pueden tener en la moral al poder hacer una lista de errores, y el progreso en solucionarlos, a veces el beneficio de la moral es crucial incluso en proyectos de una sola persona.
• La detección precisa de errores puede ser muy difícil después del hecho: ver un error en el código puede ahorrar mucho trabajo posterior en la detección de detectives, tratando de averiguar dónde ocurrió el problema originalmente.
• Es bueno que su desarrollo general como desarrollador preste atención a los errores a medida que los ve, y adquiera el hábito de mejorar / limpiar / leer el código de forma crítica.

El registro de errores cuando los encuentra es, en general, un buen hábito.

(algunos) CONS

La introducción de errores en un sistema de seguimiento de errores puede ser costosa y llevar mucho tiempo, y puede ser realmente perjudicial para el trabajo de desarrollo, más a menudo cuando se trabaja en equipos grandes. Se puede esperar que:

• compruebe si su entrada es un duplicado antes de ingresar (esto incluso podría ser implícito, es desalentador ingresar su error en la cola solo para cerrarlo)
• proporcione casos de prueba repetibles para su informe
• acepte las interrupciones posteriores con preguntas sobre los detalles del error, para aceptar / verificar una solución cuando se escribe
• piense en la información no relacionada que a menudo se recopila en los sistemas de seguimiento de errores, como cuál es el producto más afectado, la prioridad del error, etc ...

A veces, el seguimiento de errores no es el uso más eficiente de tu tiempo.

Estos son dos principios generales que pueden ser difíciles de equilibrar: encontrar una buena estrategia es un poco un arte. En situaciones como estas, creo que es mejor adoptar una heurística flexible, que modifico según sea necesario para un proyecto, equipo, entorno de trabajo y sus habilidades generales. Mi estrategia generalmente sigue un patrón como el siguiente:

• Siempre registre los problemas tal como los ve a lo largo del día, en algún lugar. Tal vez en un pegajoso, tal vez en un archivo al lado. Tal vez todo lo que registre sea un nombre de archivo y un número de línea, tal vez más. No permita que el problema interrumpa demasiado su línea de pensamiento actual.

• Tómese un tiempo al comienzo de cada nueva jornada laboral, como parte de su preparación para el trabajo, para lidiar con los problemas. Tomo de 10 a 15 minutos para revisar mi lista de problemas detectados desde el día anterior y hacer lo más rápido posible:

  • Solucione el problema y confírmelo (probablemente para una corrección de líneas o errores tipográficos). Si no tiene permitido cometer sin un informe de error, cree un proyecto paralelo para pequeños compromisos. Cuando se acumulan suficientes correcciones en el proyecto paralelo, tómese las pocas horas que necesita para documentarlas y confirmarlas.
  • Registre el problema en un sistema de seguimiento de errores (para los problemas obvios que tardan más en solucionarse, pero sin gastos generales excesivos)
  • Registre el problema en un documento "para mirar cuando no esté ocupado" (normalmente agrego un "// TODO: esto se ve roto, repárelo" escriba un comentario en la fuente). Regularmente, tome un día (intento una vez al mes) para revisar la lista y registrarla según corresponda: solicitud de características, informe de errores, discusión con el administrador, etc. ...

Con el tiempo, he encontrado todo tipo de ajustes como útiles. Por ejemplo:

• En entornos más rígidos, podría descargar el trabajo de informe de errores al equipo de pruebas; conseguir que un probador se reúna conmigo durante una hora de vez en cuando, entregarles la lista de problemas y hacer que hagan el explotación florestal. En entornos donde las pruebas de registro son importantes, por lo general, el probador se alegrará por el aumento gratuito de su productividad.
• Algunos equipos se niegan a permitir cualquier corrección que no tenga un informe de error del cliente detrás de ellos. Mantendría un proyecto lleno de correcciones en el costado y las comprometería instantáneamente cuando un cliente informara del problema relevante, para obtener puntos de brownie gratuitos.
• Algunos equipos requieren que la persona que "posee" una porción de código sea la que realice las correcciones. Yo trataría el código "propietario" como un conductor de prueba y me reuniría informalmente para entregar los problemas de vez en cuando

Encuentro que, en general, a medida que sigue este tipo de estrategia, más y más de sus compañeros y otros miembros de la compañía comenzarán a respetar su trabajo y su compromiso con la calidad. Después de un tiempo suficiente, tendrá el respeto y la autoridad necesarios para optimizar todo el proceso a su gusto. Esté atento a tales oportunidades y tómelas según corresponda.

Creo que si un desarrollador se encuentra con un error que no está relacionado con lo que está trabajando y que no se solucionará, deben ingresarlo en el sistema solo para tener un registro de algo de . De esa manera, cuando el control de calidad comienza a probar (y aún no están resueltos), puede darles a esta lista los errores como "defectos conocidos" para que no comiencen a informar los mismos errores.

Tal vez otros desarrolladores que encuentran errores lo rastreen por su cuenta si planean solucionarlo, pero en ese caso corren el riesgo de que 2 desarrolladores encuentren y solucionen el mismo error de forma independiente.

Yo agregaría que incluso si el error ya se ha solucionado (lo que no debería haber ocurrido antes de registrarlo en un rastreador de problemas) es una buena idea rastrearlo.

De esta manera, si el problema vuelve a surgir en el futuro (¡las regresiones ocurren!) es relativamente fácil reconocer el problema como "ya tratado" y leer cómo se solucionó la primera vez.

¿Por qué es eso? Debido a que la mayoría de los desarrolladores consideran el problema que tienen que plantear y el código que deben escribir, se dan cuenta de que es más fácil no molestar.

Pero, si eso es lo correcto, depende de su proceso. ¿Tienes un equipo de control de calidad? ¿Crees que a ellos les importa si solo cambias el código que no se va a rastrear? ¿Qué pasa con las revisiones de código? ¿Se saltará por esa grieta? ¿Qué pasa con el negocio? ¿Necesitan saber que has corregido un error para que no se genere el mismo más tarde?

¿Qué pasa con otros desarrolladores? ¿Qué pasa si lo arreglan de una manera diferente al mismo tiempo? ¿Qué pasa si encuentran un error similar más adelante y todo lo que puedes hacer es decir "oh, maldita sea, sé que hemos tenido algo así antes, ahora qué fue?"

Hay aproximadamente un millón de razones para registrar errores en el sistema de seguimiento de errores. Si está SEGURO de que no tiene ninguno de esos problemas, no se preocupe. Pero si no está seguro, debe grabarlo, incluso si la mayoría de las personas no lo hacen.

La programación es un trabajo complejo fundamentalmente. Los bichos son complejos. así que solía evaluar un error por dos factores:

1. ¿Con qué frecuencia pueden volver a aparecer este tipo de errores en el futuro? Ya sea que esta estimación sea precisa o no, siga estimando.
2. Cuando este tipo de errores aparecen de nuevo, ¿es fácil de entender? Esto es preciso cuando analizas este error y lo arreglas.

Clasificaría un error en uno de los siguientes tipos:

1. Es probable que vuelva a aparecer en el futuro y sea fácil de entender
2. Es probable que vuelva a aparecer en el futuro, pero es difícil de entender
3. Rara vez aparece de nuevo en el futuro y es fácil de entender
4. Rara vez aparece de nuevo en el futuro, pero es difícil de entender

En el caso 1, un libro de cocina o preguntas frecuentes es un buen dispositivo para que el equipo corrija estos errores en el futuro.

En el caso 2, un registro elaborado y comprensible es necesario para el equipo porque es un desperdicio de esfuerzo si otro programador vuelve a soportar tales errores. Por ejemplo: pérdida de memoria.

En el caso 3, creo que no es un gran problema que no quede nada para el registro porque no pasará demasiado tiempo para solucionar un error fácil. Por ejemplo, un error tipográfico para la identificación del elemento en HTML.

En el caso 4, estos errores crean un dilema. Se necesita algo de tiempo para escribir un registro elaborado y comprensible para describir dichos errores. Pero este disco rara vez se utiliza en el futuro. Sin un registro, sin embargo, la aparición de tales errores sería una lucha de nuevo. Por ejemplo, estos errores aparecen debido a un virus informático en la computadora de alguien.

Por supuesto que debes introducirlo. O al menos infórmeselo a su personal de control de calidad si ese es su proceso normal.

Incluso si solo corrige el error, querrá un registro del cambio para que luego pueda probarse y asegurarse de que la solución realmente funciona y que no haya una regresión. También es posible que un usuario pueda informar el error en algún momento, y si está en el sistema y marcado como corregido, su personal de soporte puede decirle que ya se ha solucionado.

De hecho, deberías estar grabándolos en el sistema, y en caso de que no se practique, es bueno comenzar.

En mi pasado formaba parte de un equipo de productos, estábamos en la versión beta de un nuevo producto y, a veces, ocasionalmente encontrábamos errores que en ese momento solíamos anotar y enviar por correo a las personas respectivas que manejaban los módulos. (Teníamos un sistema de seguimiento de errores, pero no pensamos en empujarlos allí). Más tarde, cuando pasaron los días, los elementos del correo empezaron a ignorarse debido a otras prioridades y eso eventualmente llevó a algunas noches de insomnio.

Entonces, ¡bang un día, Nirvana! ¿Por qué no estamos utilizando el rastreador de errores, incluso si ha encontrado algo que parece ser un error y es posible que no lo sea (su pensamiento acerca del proceso es incorrecto / defectuoso)? Al menos en la lista, que luego podría probarse, y lo más importante de todo , es un comentario sobre por qué es crítico o por el otro lado es perfecto y así es como debería funcionar debido a razones 1 ... 2 ....

Ahora tiene la lista y también para aquellos que no han entendido algunas partes de la aplicación, tienen comentarios basados en los cuales pueden aclarar sus ideas. Una situación de ganar-ganar.

Suponiendo que su código ya probado (y particularmente si se lanzó) absolutamente.

Hay varias razones para esto:

Memoria : es muy poco probable que el sistema olvide el error, cualquier desarrollador puede.

Métricas : la cantidad de errores encontrados, cerrados y el tiempo empleado pueden ser buenas métricas fáciles de capturar para decirle cómo está progresando la calidad de su código

Urgencia : puede parecer la cosa más importante para el desarrollador en el mundo, sin embargo, el tiempo empleado en solucionar este problema puede ser mejor empleado en algo que los usuarios finales desean primero (consulte también la memoria ).

Duplicación : tal vez ya haya sido detectado y esté siendo examinado / arreglado por otra persona. Alternativamente, tal vez se haya apartado de la regla de urgencia y se haya pospuesto. Por supuesto, el hecho de que lo haya encontrado de nuevo no solo significa que no se debe hacer, sino que puede significar que (a medida que sigue apareciendo) eso es ahora más urgente de solucionar.

Análisis de causa raíz : el error más fácil de corregir es el que nunca estuvo allí. Puede ser que el equipo deba estar observando este error para descubrir cómo llegó a ser. Definitivamente, esto no es para castigar al responsable (que nunca ayuda) sino para averiguar cómo se puede evitar la situación en el futuro.

Análisis de impacto más amplio : el error más barato de encontrar es el que conocía antes de encontrarlo. Al observar este error (especialmente después de hacer el análisis de la causa raíz), puede quedar claro que este problema podría existir en otros lugares del código. Como resultado, el equipo puede elegir encontrarlo antes de que levante su fea cabeza en un momento más embarazoso.

La cantidad de tiempo que se gasta en estos (si corresponde) depende en gran medida de la madurez y el nivel de calidad del código. Es probable que el análisis de la causa raíz sea excesivo para un pequeño equipo que trabaja en el código de demostración, pero es probable que un equipo grande en desarrollo empresarial crítico necesite aprender las lecciones de manera efectiva y eficiente.

Por experiencia, hay dos razones generales por las que los desarrolladores evitan usar la herramienta:

1. La herramienta de manejo de errores y / o el proceso se perciben como demasiado pesados para el desarrollo
2. Los desarrolladores encuentran que el desafío mental de arreglar el error es más interesante que las cosas en las que están trabajando actualmente.

El artículo 1 implica que puede requerirse un sistema mejor / más simple; o alternativamente, podría ser necesaria una justificación más convincente del sistema existente.

El elemento 2 debe ser una señal de advertencia útil para el líder de desarrollo sobre las asignaciones de tareas actuales.

En general, estoy de acuerdo con FrustratedWithFormsDesign, pero creo que es aún más claro si todo el problema se divide en dos áreas:

• Informe de errores.
• Corrección de errores.

Estos a menudo se tratan como si fueran iguales y separarlos probablemente ayudará mucho.

Estos se pueden manejar con: Informe de errores: - póngalo en el sistema, como dice todo el mundo.

Solución de errores: - Cada una o dos semanas (ajustarse a su programa de desarrollo, etc.), todos se reúnen en el proyecto y deciden qué debe arreglarse, quién debe hacerlo, etc. Todos estuvieron en la misma página y pueden ver lo que hay que hacer. En Desarrollo ágil, esta es la reunión de planificación de Sprint.

Una buena herramienta que la gente quiere usar también hace una gran diferencia. Me gusta Pivotal Tracker y pasé la prueba de 'herramienta realmente útil' cuando comencé a usarla solo para hacer un seguimiento de las cosas que quiero hacer o corregir en mis propios proyectos privados.

¡Si ves algo, entonces di algo!

Incluso ingreso informes de errores sobre mis propios módulos porque no quiero interrumpir mi tarea actual. Y puedo asegurar que todos los pasos para reproducir estén incluidos :-)

Y es incluso mejor cuando alguien más puede ver que has listado algo como un error conocido. Les gusta saber que alguien más lo ha encontrado también.

Creo que esto es más una pregunta política que una pregunta sobre la mejor práctica.

• ¿la entrada de errores culpa a sombody?
• el cliente puede leer las entradas de errores y ve que hay errores adicionales. ¿Es este un problema de reputación para su empresa?
• ¿es realmente un error o una característica que no conoces?
• ¿quién pagará la corrección de errores?

En mi opinión, es una buena práctica agregar errores no triviales en el sistema de seguimiento, pero la administración tiene que decidir cómo lidiar con esto.

Para casos no triviales, no debe solucionar el problema sin consultar a otra persona para asegurarse de que

• esto es realmente un error y no una característica
• sombody else puede probar la solución y asegurarse de que la solución no presente un nuevo error elsewere (regresión)