Lanza algo para unos miles de usuarios y lo primero que aprendes es que no llega un reporte por cada bug.
Un solo proceso de pago roto produce cuarenta reportes en una tarde. Si los tratas de forma ingenua, son cuarenta elementos que leer, cuarenta que clasificar y treinta y nueve que cerrar como duplicados. El día de más actividad de tu bug tracker es el que menos información produce.
Reportes y tareas son cosas distintas
BugDump los mantiene separados, y esta es la decisión estructural sobre la que se apoya todo lo demás.
Un reporte es un envío de un usuario en un momento concreto: su descripción más todo lo que capturó el SDK. Los reportes son pruebas inmutables. Nunca se editan, nunca se fusionan, nunca se deduplican.
Una tarea es lo que arreglas. Tiene un ID público, una columna en el tablero, comentarios y un historial de actividad.
Muchos reportes se adjuntan a una tarea. Cuarenta reportes sobre el pago se convierten en una tarea con cuarenta pruebas.
La distinción no es burocracia. Refleja algo cierto: las pruebas y el trabajo son objetos distintos con ciclos de vida distintos. Las pruebas se acumulan y nunca cambian. El trabajo pasa por estados y al final termina. Los sistemas que los mezclan te obligan a elegir: o pierdes pruebas al fusionar duplicados, o te ahogas en elementos porque cada prueba es también una tarea.
Los duplicados son un activo
Cuando los reportes se adjuntan a tareas, los duplicados dejan de ser ruido. Se convierten en tu mejor señal para depurar.
Cuarenta reportes en una tarea te dan algo que ningún reporte suelto puede darte: la intersección.
Si los cuarenta son de Safari, es un bug de Safari, y lo sabes antes de abrir un depurador. Si abarcan todos los navegadores pero comparten un viewport de menos de 768px, es un problema del diseño responsive. Si se concentran en una ventana de quince minutos y luego paran, fue un despliegue, y deberías mirar lo que se publicó en lugar de tu código.
Ese análisis lleva segundos cuando los reportes están agrupados y es casi imposible cuando son cuarenta elementos sueltos en una lista. La forma más común de un incidente real, mucha gente tropezando con lo mismo, es justo la que peor maneja una bandeja plana.
Aquí es también donde el servidor MCP se gana su sitio. «Lee los reportes de #17 y dime qué navegadores están afectados» es una pregunta que un agente responde en segundos leyendo los cuarenta. Comparar reportes entre sí es tan tedioso que las personas se lo saltan, y por eso vale la pena automatizarlo.
El tablero
Las tareas viven en un tablero kanban con las columnas que tú definas. Cada columna corresponde a uno de dos estados: abierto o cerrado.
Lo que importa es esa correspondencia, no el nombre. Podrías usar:
Triaje → Confirmado → En progreso → Hecho → No se arreglará
Las tres primeras son open y las dos últimas, closed. O podrías usar algo completamente distinto: con el modelo de dos estados, el sistema entiende qué cuenta como pendiente, llames como llames a tus columnas.
Dos estados, no cinco. Toda taxonomía del tipo «Aplazado / Bloqueado / Falta información / Esperando al cliente» que he visto termina igual: una columna que se llena de tareas que nadie vuelve a mirar. Si una tarea no está hecha, está abierta, y el trabajo abierto tiene que estar a la vista.
Que No se arreglará corresponda a closed también es deliberado. Decidir no arreglar algo es una resolución real. Tiene que salir de tu cola de abiertos.
Un ciclo de triaje que funciona
Lee los reportes nuevos y agrúpalos. La mayoría son duplicados. Adjúntalos a tareas existentes. Son los diez minutos que más rinden de todo el proceso: cuarenta elementos se convierten en seis.
Crea tareas para lo que de verdad es nuevo. Una por cada bug distinto.
Usa la intersección. En cualquier tarea con varios reportes, mira qué tienen en común antes de mirar el código.
Muévela, no la anotes. La posición en el tablero es el estado. Una tarea en En progreso con un comentario que dice «en realidad está bloqueada» es una tarea en la columna equivocada.
Cierra cosas. También las que no vas a arreglar.
Cerrar el ciclo
Cada proyecto puede publicar un portal público en your-project.bugdump.com, donde quienes reportan siguen las tareas que enviaron.
Esta es la parte que la mayoría de las herramientas se salta, y es la que decide si sigues recibiendo reportes.
Un usuario que reporta un bug y no vuelve a saber nada concluye que reportar no sirve de nada. Saca una conclusión racional a partir de lo que tiene delante. La próxima vez que algo se rompa, lo esquivará en silencio, y tú perderás la señal.
Un usuario que ve cómo su tarea pasa de Confirmado a Hecho ha aprendido la lección contraria. Reporta el siguiente, y el de después.
También puedes dejar que quien reporta adjunte su reporte a una tarea. Con allowTaskAttach activado, alguien que conoce el ID público de una tarea envía su reporte directamente a ella. Para equipos internos de QA y grupos de beta que ya siguen tus IDs de tareas, así te ahorras por completo el paso de triaje: quienes reportan agrupan sus propios duplicados.
La versión corta
Los reportes son pruebas. Las tareas son trabajo. Mantenlos separados, deja que los duplicados se acumulen como pruebas en lugar de pelearte con ellos, limita el tablero a dos estados reales y enséñales a quienes reportan qué pasó.
Cuarenta reportes se convierten en seis bugs, y los seis llegan con mejores pruebas de las que podría traer cualquier reporte suelto.
Te puede interesar
Cómo hacer el triaje de bugs más rápido: un flujo de trabajo con el teclado — un flujo de triaje que quita la navegación de en medio en lugar de pedirte que pienses más rápido.
Métricas de bugs que de verdad importan — cuatro métricas que responden si vas al día con los bugs, las que engañan y una revisión semanal de cinco minutos.
En mi máquina funciona: guía de campo de los bugs no reproducibles — las ocho diferencias entre tu máquina y la del usuario que explican casi cualquier bug que no puedes reproducir.