¿Qué es el seguimiento de errores? La diferencia entre un registro y un mensaje

El seguimiento de errores consiste en mantener cada defecto conocido en un solo sitio, de una forma que sobreviva a que la persona que lo encontró se vaya de vacaciones. Esa es toda la idea. El software al que la gente se refiere cuando dice “bug tracker” no es más que el archivador que lo hace posible.

La distinción que importa es la que hay entre un registro y un mensaje. Un mensaje es lo que envías cuando te das cuenta de algo: una línea de chat, un correo, un comentario de viva voz al pasar junto a la mesa de alguien. Va dirigido a una persona, se lee una vez y desaparece. Un registro no va dirigido a nadie en particular y se lee cada vez que alguien hace la pregunta adecuada. El seguimiento de errores es la práctica de convertir lo primero en lo segundo.

Lo que un sistema de seguimiento tiene que hacer

Cuatro cosas. Todo lo demás es comodidad.

• Guardar una entrada por problema, para que dos personas que encuentran lo mismo se encuentren entre ellas en lugar de informar dos veces.
• Decir en qué punto está cada una - abierta, en curso, corregida, verificada, cerrada - de una forma que sea cierta y no un deseo.
• Nombrar a un responsable, porque un defecto que pertenece al equipo no pertenece a nadie.
• Poder buscarse después, que es lo que la gente se salta al elegir y lamenta en el cuarto mes.

Una hoja de cálculo hace mal las tres primeras y la cuarta no la hace en absoluto. Un canal de chat no hace ninguna, lo cual no es una crítica al chat: es un medio de mensajes haciendo exactamente aquello para lo que sirve.

Lo que va en una entrada

Menos de lo que piden la mayoría de las plantillas y más de lo que llevan la mayoría de los informes.

Las partes que se ganan su sitio son las que otra persona necesita para actuar: qué pasó, qué se esperaba en su lugar, cómo volver a ello y dónde ocurrió - navegador, versión, cuenta, URL. Nuestra guía para escribir un informe de error es la versión larga de esa lista, y trae una plantilla que puedes pegar en un formulario.

Todo lo demás de un formulario típico son metadatos del proceso y no del problema: severidad, prioridad, componente, hito, la persona responsable. Útil, pero pertenece a quien lleva la gestión de defectos, no a quien se ha dado cuenta de que el botón estaba roto. Pedírselo a quien informa, en el momento de informar, es la manera más común de encarecer el informe hasta que la gente deja de escribirlo.

Tres formas de fallar

Casi todos los sistemas de seguimiento que dejan de merecer confianza llegan ahí por una de tres vías.

El cementerio. No se cierra nada nunca, así que la cuenta solo crece, así que nadie lee la lista, así que llegan defectos reales y no se ven nunca. Un atraso de ochocientas incidencias que nadie ha abierto este año no es el registro de nada; es un sitio al que van a parar las cosas.

Estados que mienten. Cada entrada dice “abierta” porque moverlas es trabajo de alguien y nadie lo tiene. A esas alturas el campo de estado es decoración y la única forma de saber en qué punto está algo es preguntarle a una persona, que es justo lo que el sistema venía a sustituir.

El montón de duplicados. El mismo defecto informado seis veces porque buscar cuesta más que escribir. Se suele culpar de esto a quien informa y suele ser un problema de búsqueda: si buscar las palabras que usaría una persona normal no encuentra la entrada que ya existe, el sistema le ha enseñado a informar otra vez.

De dónde vienen las entradas importa más que qué herramienta las guarda

Los equipos dedican mucho tiempo a elegir entre sistemas de seguimiento y casi ninguno al paso anterior, que es cómo llega un defecto desde la persona que lo vio hasta el sistema.

Ese trayecto es donde mueren los informes. Alguien nota un problema y, entre notarlo y haber escrito una entrada útil, hay un hueco: qué navegador era, qué decía la consola, cuál era la URL, en qué hice clic primero. La mayoría de la gente, la mayoría de las veces, escribirá dos frases y seguirá con lo suyo, porque la alternativa son quince minutos de investigación por un error que no es suyo.

Cualquier cosa que acorte ese hueco eleva la calidad de todo lo que viene después. Un formulario en la página donde ocurrió el error gana a un enlace al sistema de seguimiento. Una captura que recoge la mitad técnica de forma automática gana a pedirle a un agente de soporte que abra las herramientas de desarrollo. Capturar el informe donde está el error es el mismo problema visto desde el otro extremo.

Elegir uno

El consejo honesto es que la elección importa menos que la costumbre. Jira, Linear, GitHub Issues, Bugzilla, Trello con una columna llamada Bugs: las cuatro cosas de arriba se pueden conseguir en cualquiera de ellos, y ninguno las hará por ti.

Vale la pena hacerle dos preguntas a un candidato, y no son las de las páginas comparativas:

Pregunta floja

¿Cuál tiene más integraciones y los mejores paneles de informes?

Pregunta mejor

¿Puede alguien que no está en el equipo de desarrollo informar en él sin ayuda, y puede alguien encontrar una entrada de hace dos años con las palabras que recuerda?

Si informar exige una cuenta, un proyecto, un componente y un tipo de incidencia, las personas más cercanas a tus clientes - soporte, ventas, QA, el propio cliente - no informarán. Sus errores llegarán como mensajes, y la diferencia entre un registro y un mensaje era justo lo que intentabas comprar.

Seguimiento, pruebas y todo lo demás

El seguimiento de errores está aguas abajo de todo lo que encuentra errores, y por eso acaba recogiendo el vocabulario de todo ello. Un plan de pruebas dice cómo se informan los defectos y quién decide si uno detiene una entrega. Las pruebas de regresión existen porque un sistema lleno de entradas cerradas es una lista de cosas que antes funcionaban. Las pruebas inestables son lo que pasa cuando aquello que se sigue no acaba de decidir si es un defecto.

Un sistema de seguimiento no mejora el software. Evita que la misma tarde se gaste dos veces.