"Este bug es urgente" y "este bug es grave" suenan casi como lo mismo, pero no lo son — y confundirlos es una de las razones más comunes por las que un equipo discute en círculos sobre qué arreglar primero. Severidad y prioridad son dos preguntas distintas, y un bug puede tener una combinación de ambas que sorprende si no se separan con claridad.
Severidad: qué tan roto está el sistema
La severidad mide el impacto técnico del bug, sin importar el contexto del negocio en ese momento: ¿se pierde información? ¿se cae el sistema? ¿es un problema puramente visual? Es una propiedad del bug en sí mismo, y normalmente la define quien lo encuentra o el equipo técnico.
Prioridad: qué tan rápido hay que arreglarlo
La prioridad mide la urgencia de negocio: ¿cuánta gente lo está sufriendo ahora mismo? ¿hay una fecha de lanzamiento cerca? ¿existe una solución temporal mientras se arregla de raíz? Normalmente la define el equipo de producto o quien lidera el proyecto, no necesariamente quien reportó el bug.
Por qué no siempre van de la mano
Acá está el punto que más confunde: un bug de severidad alta no siempre es de prioridad alta, y al revés. Algunos ejemplos reales:
- Severidad alta, prioridad baja: un error que hace crashear una función usada por 2 personas, una vez al mes, en un reporte interno que casi nadie mira. Es grave técnicamente, pero puede esperar al próximo sprint sin que nadie lo note.
- Severidad baja, prioridad alta: el logo de la empresa se ve mal alineado en la pantalla de login, justo el día de un lanzamiento con prensa. No rompe nada, pero lo ve todo el mundo en el peor momento posible.
- Severidad alta, prioridad alta: el checkout de una tienda no procesa pagos. Rompe el negocio y hay que arreglarlo ya — este es el caso donde ambas coinciden y no hay ninguna duda.
Una matriz simple para clasificar sin discutir cada vez
Tener una matriz acordada de antemano — no inventada caso por caso en el calor de la discusión — ahorra mucho tiempo. Una versión simple que funciona para la mayoría de los equipos:
- Severidad: Crítica (pérdida de datos, caída total), Alta (un flujo importante no funciona), Media (funciona con una solución alternativa), Baja (cosmético, no afecta el uso).
- Prioridad: Urgente (arreglar hoy), Alta (este sprint), Media (próximo sprint), Baja (cuando haya espacio).
Con las dos escalas separadas y documentadas, cada bug nuevo se clasifica en segundos — y cuando alguien no está de acuerdo con la prioridad asignada, la discusión se vuelve concreta ("¿por qué esto es Alta y no Urgente?") en vez de una pelea sobre quién tiene más criterio.
Para que esta clasificación sirva de algo con el tiempo, cada bug necesita quedar vinculado al caso de prueba que lo encontró y con su severidad/prioridad visibles de un vistazo, no enterradas en un comentario de texto — exactamente cómo QAcove organiza el registro de bugs de cada proyecto.