Diagrama de flujo del proceso de triaje de bugs
Proceso de triaje de bugs: recepción del defecto, reproducción, comprobación de duplicados, severidad y prioridad, escalado, corrección, revisión de código y verificación de QA.
Cómo funciona
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.
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.
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.
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.
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.
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.