El bug triage es el proceso de confirmar, clasificar y asignar los defectos recién reportados, para que los recursos de desarrollo limitados vayan primero a los problemas de mayor impacto. Un proceso de triage eficaz garantiza dos cosas: cada defecto se mira dentro de un plazo fijo, y una vez mirado, su destino queda decidido (arreglar, programar, degradar o cerrar).
Por qué existe el triage
Los equipos sin mecanismo de triage suelen mostrar una de dos patologías:
- Ley del que más grita: quien más se queja lo arreglan primero; los P0 y los P2 esperan en la misma cola;
- Agujero negro: los defectos se dispersan entre chats, correos y feedback verbal, y una buena parte nunca la «decide» nadie.
El triage existe para dar a todos los defectos una entrada única y un punto de decisión: cada elemento entrante se verifica en 24 horas, recibe severidad y prioridad, y encuentra dueño.
Los roles del triage
| Rol |
Responsabilidad |
| Facilitador del triage (normalmente el QA lead) |
Conduce la reunión de triage, mantiene la cola a cero, impulsa las decisiones |
| QA / testers |
Verifican reproducibilidad, completan los pasos de reproducción, clasificación preliminar |
| Responsable de desarrollo |
Evalúa el impacto técnico, estima el coste de corrección, acepta las asignaciones |
| Product owner (PM/PO) |
Fija la prioridad de negocio, zanja los desacuerdos de «¿se arregla o no?» |
Los equipos pequeños pueden unir QA lead y PM en una persona — pero ambas perspectivas, juicio técnico y juicio de negocio, deben estar presentes.
El flujo de triage estándar (5 pasos)
1. Ingerir y deduplicar
Los informes de todos los canales (pruebas internas, usuarios beta, feedback de producción) aterrizan en el mismo registro y se fusionan tras deduplicar por «módulo + síntoma». Las entradas dispersas son la raíz del fracaso del triage — el bug reportado en el chat y el reportado en la herramienta deben acabar en una sola tabla.
2. Validar
- ¿Reproducible? Recorre los pasos del informe;
- No reproduce: anota la información del entorno y devuélveselo al reportante para que complete — los equipos cuyos informes traen el contexto del entorno casi no se atascan aquí (ver más abajo);
- No es un defecto (comportamiento esperado / duda de uso): conviértelo en consulta de soporte o mejora de documentación, ciérralo y avisa al reportante.
3. Clasificar (Severidad × Prioridad)
La severidad (visión técnica) y la prioridad (visión de negocio) son dos dimensiones; no las confundas:
| Prioridad alta |
Prioridad baja |
| Severidad alta |
Arreglar ya (la página de inicio se queda en blanco) |
Arreglar este sprint (una función de cola se rompe, sin alternativa, pero casi nadie llega hasta ella) |
| Severidad baja |
Arreglar pronto (botón de login desalineado, afecta a todos los usuarios) |
Al backlog (una errata en una esquina de la página) |
El error habitual es asumir «severidad = prioridad»: así se queda hambriento para siempre un montón de problemas «no letales técnicamente pero bochornosos para el negocio».
4. Asignar y programar
- P0: hotfix o rollback el mismo día, avisar a todos los afectados;
- P2/P3: al Product Backlog, ordenados como siempre.
5. Devolver y cerrar
Tras la corrección: pedir al reportante (sobre todo si es un tester externo) que reverifique → verificación superada → cerrar y registrar la categoría de causa raíz (para las estadísticas de la retrospectiva). Devolver el estado al reportante externo decide directamente si volverá a reportar.
Cómo dirigir la reunión de triage
- Frecuencia: los equipos de iteración rápida se reúnen a diario, 15–30 minutos, solo elementos nuevos; los ritmos más lentos, 2–3 veces por semana;
- Formato: recorrer el tablero del registro, 3–5 minutos por elemento; lo que no se decida en 5 minutos pasa a «pendiente» y se zanja en un 1:1 antes de fin del día;
- Disciplina: la reunión decide, no diseña soluciones técnicas; solo elementos nuevos, lo ya clasificado no se renegocia.
El prerrequisito de un triage rápido: informes que traen contexto
La escena que más tiempo quema en una reunión de triage: QA lee un informe — «el usuario dice que el botón no hace nada» — y todos empiezan a preguntar: ¿qué página? ¿qué navegador? ¿hay errores en Console? ¿puedes hacer clic otra vez? Un informe que debería clasificarse en 2 minutos se convierte en un policíaco de 15.
La causa raíz es un informe sin contexto. Compara:
| Información |
Informe manual (el usuario narra de memoria) |
Informe recogido automáticamente |
| Pasos de reproducción |
«Hice clic en ese botón y no pasó nada» |
Captura/grabación anotada que señala el lugar y la acción |
| URL de la página |
A menudo ausente o mal recordada |
Adjunta automáticamente |
| Navegador/dispositivo |
Normalmente ausente |
Adjunto automáticamente |
| Errores Console / Network |
Prácticamente imposible |
Stack traces de ERROR y peticiones fallidas adjuntas |
La columna de la derecha no es fantasía — es exactamente cómo funciona BugCapturer: cuando los usuarios (incluidos beta testers totalmente no técnicos) envían feedback, el informe lleva automáticamente la captura/grabación anotada, la URL, el entorno del navegador y los errores Console/Network (ver la función de diagnóstico). En la reunión de triage se recorre el registro, 2 minutos para clasificar cada elemento; la proporción de «no reproduce» en la validación baja de forma notable. Los informes se empujan automáticamente a un canal de Slack / Microsoft Teams para un seguimiento unificado — la deduplicación y las estadísticas ganan una única fuente de verdad.
Métricas de autocomprobación de la calidad del triage
| Métrica |
Valor sano |
Significado |
| Primera respuesta a un informe |
< 24 h |
Desde el envío hasta la decisión de triage |
| Acumulación de «pendientes» |
< 5 % |
Pendientes longevos = criterios de clasificación poco claros |
| Tasa de informes duplicados |
a la baja |
El registro y la deduplicación funcionan |
| Número de P0 |
a la baja |
Persistente alto = falta actividad de calidad aguas arriba |
| Tasa de reverificación de los reportantes |
alta |
Satisfacción y retención de los testers externos |
Estas métricas también alimentan la retrospectiva de sprint — ver «Apoya la retrospectiva con datos» en la guía de sprint retrospective.
FAQ
P: ¿Qué es el defect triage?
R: El proceso de decisión para los defectos nuevos: validar, deduplicar, clasificar (severidad × prioridad), asignar. Suele ejecutarse como reunión de triage a cadencia fija, con QA, desarrollo y producto juntos.
P: Bug triage vs bug tracking — ¿cuál es la diferencia?
R: El tracking es la herramienta y el mecanismo para registrar y seguir el estado de los defectos; el triage es el proceso que toma una decisión de tratamiento por cada defecto. El registro es tracking; el triage es la capa de decisión que corre sobre el registro.
P: ¿Un equipo pequeño necesita un proceso de triage?
R: Sí, pero mínimo: sin reunión; el QA lead dedica 15 minutos fijos al día a recorrer el registro, clasificar y asignar. Lo que importa es el resultado — cada defecto ha quedado explícitamente decidido.
P: El reportante no es técnico, ¿cómo garantizamos informes utilizables?
R: No pidas datos técnicos al reportante; recógelos automáticamente. Herramientas como BugCapturer adjuntan URL, entorno y errores Console/Network al enviar — incluso los informes de legos se pueden triagear directamente.
P: Cuando la severidad y la prioridad chocan, ¿quién manda?
R: La prioridad es el orden de ejecución final, decidido por el product owner en la reunión de triage; la severidad es un input técnico que informa la decisión, no un sustituto de ella.