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

Durante el desarrollo (características o correcciones de errores), a veces descubro errores que no están directamente relacionados con lo que estoy trabajando. ¿Qué debo hacer en esa situación? ¿Solo arreglarlo? ¿Intentas recordar arreglarlo más tarde? Escríbelo en alguna parte? ¿O ingresarlo en el sistema de seguimiento de errores?

Generalmente lo ingreso al sistema de seguimiento de errores y dejo que el proceso se desarrolle solo (es decir, triaging, asignación, etc.). Sin embargo, casi nunca he visto a otro desarrollador ingresar un error. (¿Porqué es eso?)

Si descubre un error, no se me ocurre ninguna buena razón para no ingresarlo en el sistema de seguimiento de errores, ya sea que lo arregle o no. Para eso es 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 rastrear el error.

Es posible que haya alguna razón, válida o no, para que los desarrolladores no ingresen errores. Una posible razón podría ser que el sistema de seguimiento de errores es visible para los extraños, 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 rastrear errores. Pregúntale a tu jefe.

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

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

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

• cuando el error se refiere directamente al código en el que está trabajando,

• cuando el error se refiere al código en el que no está trabajando en este momento o la parte en la que trabaja otro desarrollador.

Esto es esencial, ya que el sistema de seguimiento de errores está hecho para ... rastrear errores. Cada error Si descubre que algo anda mal, no lo arregle. Documente a través del sistema de seguimiento de errores. Cuando más tarde, un cliente que ejecute una versión anterior del software informe un error que sea un duplicado exacto, podrá vincularlo a su informe. Si no tiene nada con lo que vincularse, perderá su tiempo (o su colega) buscando el error en revisiones anteriores, luego intente resolverlo y finalmente descubra que el error ya se resolvió mágicamente.

Esto también explica por qué los trabajadores independientes 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, arregle el proceso.

Las razones para no ingresar son:

• El proceso mide y castiga en base a la notificación de defectos: no informe, no se castigue. En este caso, abandone la organización.
• El proceso es una carga: lleva demasiado esfuerzo y tiempo ingresar un defecto y llegar al punto de repararlo. El proceso debe cambiarse para permitir a los desarrolladores rastrear rápidamente un error ligero a través del proceso de triaje / aceptar / arreglar.
• Algunos desarrolladores son perezosos / descuidados / piratas informáticos a los que no les importa cuál sea el impacto de las cosas que hacen en los demás. Recluta desarrolladores profesionales.
• Soy una banda de un solo hombre, no entiendo el punto. Ve a trabajar para una banda de 2 hombres y ...

Reparar el error de inmediato es probablemente una mala idea. Primero, alguien más podría estar trabajando en la misma solución, lo que resulta en 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 decisión de gestión y 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 múltiples 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 solucionan más fácilmente mientras ya está en una parte del código, trabajando para comprenderlo.
• Incluso en equipos más pequeños, se pueden obtener muchos beneficios morales al poder enumerar los errores y progresar en su reparación; a veces, el beneficio moral es crucial incluso en proyectos individuales.
• 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 el juego de detectives, tratando de averiguar dónde ocurrió originalmente el problema.
• Es bueno para su desarrollo general como desarrollador prestar atención a los errores tal como los ve, y adquirir el hábito de mejorar / limpiar / leer código críticamente

Registrar los errores a medida que los encuentra es, en general, un buen hábito.

(algunos) CONTRAS

Introducir errores en un sistema de seguimiento de errores puede ser oneroso 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 usted:

• verifique 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)
• proporcionar casos de prueba repetibles para su informe
• aceptar interrupciones posteriores con preguntas sobre detalles de errores, 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 qué producto es el más afectado, la prioridad del error, etc.

A veces, el seguimiento de errores no es el uso más eficiente de su 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 modifique según sea necesario para un proyecto determinado, equipo, entorno de trabajo y sus habilidades generales. Mi estrategia generalmente sigue un patrón como el siguiente:

• Siempre registra los problemas tal como los ves a lo largo del día, en algún lugar. Tal vez de forma pegajosa, tal vez en un archivo a un lado. Tal vez todo lo que registra es 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 el tiempo al comienzo de cada nuevo día de trabajo, como parte de su preparación para el trabajo, para lidiar con los adhesivos. Tomo 10-15 minutos para revisar mi lista de problemas detectados del día anterior y hacer lo que sea más rápido:

  • Solucione el problema y confírmelo (probablemente para correcciones o errores tipográficos). Si no se le permite comprometerse sin un informe de error, cree un proyecto paralelo para pequeñas confirmaciones. Cuando se acumulen suficientes arreglos en el proyecto paralelo, tómese las pocas horas que necesite para documentarlos y comprometerse.
  • Registre el problema en un sistema de seguimiento de errores (para problemas obvios que tardan más en solucionarse, pero sin una carga onerosa)
  • Registre el problema en un documento "para mirar cuando no está ocupado" (generalmente agrego un comentario "// TODO - esto parece roto, corríjalo" en la fuente). Regularmente me tomo un día (lo intento una vez al mes) para revisar la lista y registrarla según corresponda: solicitud de funciones, informe de errores, discusión con el gerente, etc.

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

• En entornos más rígidos, es posible que descargue el trabajo de informe de errores al equipo de prueba: haga que un probador se reúna conmigo durante una hora de vez en cuando, entrégueles la lista de problemas y haga que hagan el registro. En entornos en los que las pruebas de registro son un gran problema, por lo general, el probador estará contento con el impulso gratuito de su productividad.
• Algunos equipos se niegan a permitir correcciones que no tengan un informe de error del cliente detrás de ellos. Mantendría un proyecto lleno de correcciones al margen, y las confirmaría instantáneamente cuando un cliente informara el problema relevante, para obtener puntos de brownie gratuitos.
• Algunos equipos requieren que la persona que "posee" un trozo de código sea quien realice las correcciones. Trataría al "propietario" del código como una pista de prueba y me reuniría informalmente para resolver problemas ocasionalmente

Creo que, en general, a medida que sigue este tipo de estrategia, más y más de sus pares y otros miembros de la compañía comenzarán a respetar su trabajo y su compromiso con la calidad. Después de suficiente tiempo, 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 encuentra un error que no está relacionado con lo que está trabajando y que no solucionará, debe ingresarlo en el sistema solo para tener algún registro. De esa manera, cuando QA comienza a probar (y todavía no están solucionados), puede darles estos errores de la lista como "defectos conocidos" para que no comiencen a informar los mismos errores.

Quizás otros desarrolladores que encuentran errores lo rastrean solos si planean arreglarlo, pero en ese caso corren el riesgo de que 2 desarrolladores encuentren y corrijan el mismo error de forma independiente.

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

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

¿Porqué es eso? Debido a que la mayoría de los desarrolladores analizan el problema que tienen que plantear y el código que tienen que escribir y piensan que es más fácil no molestarse.

Pero, si eso es lo correcto, depende de su proceso. ¿Tienes un equipo de control de calidad? ¿Crees que les importa si solo cambias el código que no se rastreará? ¿Qué pasa con las revisiones de código? ¿Saltará por esa grieta? ¿Qué hay del negocio? ¿Necesitan saber que ha solucionado un error para que no lo planteen 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 tarde y todo lo que puedes hacer es decir "oh, maldición, sé que hemos tenido algo así antes, ahora qué fue?"

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

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

1. ¿Con qué frecuencia este tipo de errores pueden aparecer nuevamente en el futuro? Si esta estimación es precisa o no, siga estimando.
2. Cuando vuelven a aparecer este tipo de errores, ¿es fácil de entender? Esto es exacto cuando analiza este error y lo arregla.

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

1. Probablemente aparezca de nuevo en el futuro y fácil de entender.
2. Probablemente aparezca de nuevo en el futuro, pero difícil de entender.
3. Raramente aparece de nuevo en el futuro y es fácil de entender.
4. Raramente 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 solucione dichos 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 resiste esos errores nuevamente. Por ejemplo: pérdida de memoria.

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

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

Por supuesto que debes ingresarlo. O al menos repórtelo a su personal de control de calidad si ese es su proceso normal.

Incluso si solo soluciona el error usted mismo, querrá un registro del cambio para que luego se pueda probar para asegurarse de que la solución realmente funcione y que no haya habido una regresión. También es posible que un usuario informe el error en algún momento, y si está en el sistema y está marcado como solucionado, su personal de soporte puede decirles que ya se ha solucionado.

De hecho, debería 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 producto, y estábamos en la versión beta de un nuevo producto y, a veces, ocasionalmente encontramos 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 en el correo comenzaron a ser ignorados debido a otras prioridades y eso eventualmente condujo a algunas noches de insomnio.

¡Entonces, golpea un día, Nirvana! ¿Por qué no estamos usando el rastreador de errores, incluso si encontró algo que parece un error y podría ser posible que no lo sea (su pensamiento sobre el proceso es incorrecto / defectuoso)? Al menos forma parte de 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 otro lado, es perfecto y así es como debería funcionar debido a las razones 1 ... 2 ... .

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

Asumiendo su código ya probado (y particularmente si se publica) absolutamente.

Hay un número de razones para esto:

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

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

Urgencia : puede parecer lo más importante del mundo para el desarrollador, sin embargo, el tiempo dedicado a solucionar este problema puede invertirse mejor en algo que los usuarios finales quieren primero (ver también memoria).

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

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

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

La cantidad de tiempo que se dedica a estos (si corresponde) depende en gran medida del nivel de madurez y 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 un gran equipo de desarrollo crítico del negocio probablemente necesite aprender las lecciones de manera efectiva y eficiente.

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

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

El ítem 1 implica que se puede requerir un sistema mejor / más simple; o, alternativamente, una justificación más convincente del sistema existente podría estar en orden.

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

Principalmente 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 iguales y la separación de ellos seguramente ayudará mucho.

Estos pueden manejarse con: Informe de errores: - póngalo en el sistema, como todos dicen.

Corrección de errores: - Cada semana o dos (ajustarse a su calendario de desarrollo, etc.) todos se reúnen en el proyecto y deciden qué debe arreglarse, por quién, etc. Esto fue todo el mundo está en la misma página y puede ver lo que necesita ser hecho En Agile Development, esta es la reunión de planificación de Sprint.

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

Si ves algo, ¡di algo!

Incluso ingreso informes de errores sobre mis propios módulos porque no quiero interrumpir mi tarea actual. Y puedo asegurarme de que se incluyen todos los pasos para reproducir :-)

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

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

• ¿La entrada de errores culpa a Sombody?
• ¿Puede el cliente leer las entradas de errores y ve que hay errores adicionales? ¿Es este un problema de reputación para su empresa?
• ¿Es esto realmente un error o una característica que no conoce?
• ¿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 gerencia 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 introduzca un nuevo error de lo contrario (regresión)