Diagrama de flujo del proceso de triaje de bugs

¿Qué es diagrama de flujo del proceso de triaje de bugs?

El triaje de bugs es la forma de convertir un goteo de reportes de defectos en una cola de trabajo ordenada. Cada reporte se registra, alguien intenta reproducirlo, los duplicados se enlazan al original y lo que sobrevive recibe una severidad y una prioridad para que desarrollo sepa qué coger a continuación. El nombre viene de la medicina de urgencias a propósito: el objetivo no es arreglarlo todo, es decidir rápido qué se atiende ahora, qué espera y qué se cierra.

La mayor parte del coste de gestionar defectos está antes de escribir una sola línea de código. Un reporte sin número de build ni entorno no se puede reproducir, así que rebota entre soporte y quien lo reportó durante una semana. Un defecto que nadie comprobó contra duplicados se corrige dos veces en dos ramas. Una severidad puesta por quien escaló más fuerte convierte el backlog en una negociación. Repartir el flujo en carriles hace explícito cada traspaso y le da un responsable con nombre a cada rama.

Esta plantilla es un flujo de triaje real repartido en cinco carriles: quien reporta, soporte, responsable de triaje, desarrollo y QA. Incluye las ramas que los equipos suelen dejar sin documentar: el bucle de petición de más información y el cierre por no reproducible con el que termina, el enlace de duplicados, la vía de escalado para defectos críticos o con producción caída, y el camino de reapertura cuando la verificación de QA no pasa.

Qué cubre este diagrama de flujo

En esta plantilla

• La recepción entre los carriles de quien reporta y soporte: el usuario reporta el bug y después se registra el defecto en el tracker con build, entorno, pasos exactos y comportamiento esperado frente al real.
• Un bucle de reproducción en el carril de soporte: «Intentar reproducir el defecto» y una decisión «¿Se reproduce el defecto?» que pasa el reporte a triaje o lo desvía a una petición de más información.
• El final que casi ningún diagrama dibuja: una decisión «¿Responde a tiempo?» que devuelve el reporte contestado a un nuevo intento de reproducción y cierra el que no obtiene respuesta como «Cerrado por no reproducible».
• Dos decisiones del responsable de triaje: «¿Duplicado de un defecto abierto?», que enlaza y cierra los duplicados contra el original, y después «Asignar severidad y prioridad» para todo lo que es realmente nuevo.
• Una rama «¿Crítico o producción caída?» que abre una incidencia de producción y manda la corrección directa a desarrollo, mientras los defectos estándar se asignan al equipo propietario y entran en su backlog.
• Corrección y verificación: desarrollar la corrección con pruebas unitarias, una puerta «¿Revisión de código aprobada?» que devuelve el rehacer al desarrollo, la verificación de QA en pruebas con su rama de reapertura, y la publicación en producción con aviso a quien reportó.

Cuándo usar esta plantilla

• Vais a escribir por primera vez un proceso de triaje, porque los reportes llegan por tickets de soporte, llamadas de ventas y mensajes de Slack y nadie tiene claro quién decide qué se corrige.
• Estáis fijando o reformulando las definiciones de severidad y prioridad, donde una imagen de quién las asigna y en qué paso sirve más que una política que nadie abre.
• Vas a incorporar a técnicos de soporte y responsables de triaje nuevos que necesitan ver qué decisiones son suyas y qué le pasa a un reporte cuando lo entregan.
• Vas a configurar un flujo en Jira, Linear o GitHub Issues y quieres que la herramienta recoja un proceso acordado en lugar de inventarlo a base de nombres de estado.
• Queréis reducir los defectos que llevan meses sin tocarse, haciendo explícitos el bucle de petición de información y el cierre por no reproducible en vez de dejarlos al criterio de cada uno.

Cómo funciona

1. Renombra los carriles con los roles que tienes

   Sustituye quien reporta, soporte, responsable de triaje, desarrollo y QA por tus funciones reales. Los equipos pequeños suelen fundir soporte y triaje en un solo carril, y un equipo sin QA dedicado mueve la verificación a una segunda persona de desarrollo. Usa un carril por decisor y no por persona, o el diagrama dejará de coincidir con la realidad en cuanto alguien cambie de puesto.

2. Escribe tus definiciones de severidad y prioridad en el paso de triaje

   La severidad es el impacto si el defecto ocurre; la prioridad es cuándo se va a trabajar. Define cada nivel con un ejemplo real, por ejemplo pérdida de datos o una compra bloqueada arriba y un desajuste estético abajo. Sin ejemplos, todos los reportes llegan al nivel máximo y el campo deja de aportar información.

3. Fija el umbral de escalado

   Sustituye la decisión genérica «¿Crítico o producción caída?» por tu disparador real: clientes afectados, una vía de ingresos bloqueada, datos en riesgo. Indica quién está autorizado a declarar una incidencia y dónde vive el proceso de incidencias, porque en ese punto el triaje entrega el defecto mientras el registro sigue abierto para la corrección definitiva.

4. Decide cuánto dura el bucle de información

   La decisión «¿Responde a tiempo?» necesita un plazo de espera declarado y normalmente un recordatorio. Pon el número en el paso. Sin él, los reportes que nunca fueron reproducibles se quedan abiertos para siempre y el backlog deja de reflejar el trabajo real.

5. Acuerda qué significa verificar y a dónde va una reapertura

   Indica si QA verifica con los pasos originales de quien reportó, con una batería de regresión o con las dos cosas. Esta plantilla devuelve una verificación fallida a desarrollo sobre el mismo registro, para que el histórico quede en un solo sitio. Cámbialo para que vuelva a triaje si prefieres que un defecto reabierto se vuelva a priorizar en lugar de retomarse directamente.

6. Publícalo y mantén una sola versión vigente

   Pon el diagrama junto al formulario de reporte de bugs y en el manual de guardia, recoge la aprobación de soporte, desarrollo y QA, y conserva las versiones anteriores para poder ver cuándo cambió el proceso. Revísalo después de cualquier defecto que tardara mucho más de lo debido y corrige el paso donde se atascó.

Preguntas frecuentes

¿Cuáles son las fases de un proceso de triaje de bugs?

En la mayoría de los equipos, cinco. Recepción, donde el reporte se registra con detalle suficiente para actuar. Reproducción, donde soporte confirma que el defecto existe y no es un error de configuración o de uso. Triaje, donde se enlazan duplicados y se asignan severidad, prioridad y equipo propietario. Corrección, que cubre desarrollo y revisión de código. Verificación, donde QA contrasta la corrección con el reporte original antes de publicarla y avisar a quien la reportó. El diagrama de arriba usa esas cinco como columnas de fase, y son reproducción y triaje las que cargan con las decisiones que hacen casi todo el trabajo.

¿Cuál es la diferencia entre severidad y prioridad?

La severidad describe el impacto del defecto: pérdida de datos, un flujo bloqueado, un detalle estético. La prioridad describe cuándo se va a trabajar. Responden a preguntas distintas y deben seguir siendo campos separados. Una errata en un precio publicado tiene severidad baja y prioridad alta; un fallo grave en una función que usan dos clientes puede tener severidad alta y prioridad baja. Juntarlos en un solo campo es el motivo más común de que un proceso de triaje deje de resultar creíble, porque todo acaba en lo más alto de la escala.

¿Cada cuánto hay que hacer triaje y quién tiene que estar?

Una pasada corta y recurrente sobre todo lo abierto desde la anterior: diaria en un producto de consumo en vivo, dos veces por semana con ciclos de publicación más lentos. Con tres roles suele bastar para decidir: alguien de soporte que pueda hablar del impacto en el cliente, un responsable de triaje que sea dueño de la severidad y la prioridad, y un responsable técnico que sepa qué equipo es propietario del código. Nada crítico ni con producción caída debería esperar a la reunión, y por eso este diagrama lo escala de inmediato a una incidencia en lugar de ponerlo en cola.

¿Qué hay que hacer con un bug que no se puede reproducir?

Cerrarlo, pero solo después de un bucle explícito. Pide una vez el detalle que falta (build, entorno, pasos exactos, una grabación de pantalla), insiste dentro de un plazo declarado y cierra como no reproducible dejando el motivo registrado y la puerta abierta a reabrirlo si vuelve a ocurrir. Esta plantilla dibuja ese bucle como una decisión en el carril de quien reporta en lugar de dejarlo al criterio de cada persona, porque los reportes irreproducibles abiertos para siempre son justo lo que convierte un backlog en una lista que ya nadie lee.