Severity vs Priority: La Habilidad de Triage que Hace Crecer a los Junior QA

Un bug que corrompe registros de base de datos durante una importación masiva es de severidad Crítica. Si esa importación corre una vez durante el onboarding por un único administrador con un workaround disponible, puede esperar legítimamente hasta el próximo sprint mientras el nombre mal escrito de un partner en la página de inicio sale como hotfix hoy. La severidad y la prioridad son dimensiones separadas, y este artículo cubre cómo aplicar ambas: la escala de severidad de cuatro niveles, qué impulsa las decisiones de prioridad, y los dos cuadrantes de la matriz 2×2 que confunden a la mayoría de los QA engineers junior.

Qué significa realmente la severidad

La severidad mide el impacto técnico del bug. ¿Qué tan gravemente daña este defecto al sistema? Pérdida de datos, un crash, un flujo de pago roto: son de alta severidad. Una etiqueta de botón mal alineada, un error tipográfico en un tooltip: son de baja severidad.

La severidad vive puramente en el dominio técnico. No le importan el cronograma del release, la campaña de marketing, ni cuántas personas lo verán. Responde una pregunta: ¿qué tan roto está esto, objetivamente?

La escala clásica de cuatro niveles de severidad que usan la mayoría de los equipos:

Crítico

El bug hace algo completamente no funcional, corrompe datos, crea una vulnerabilidad de seguridad o crashea la aplicación. El usuario no puede continuar. No hay workaround. Ejemplo: hacer clic en "Realizar Pedido" muestra una pantalla de éxito, pero el pedido nunca se escribe en la base de datos.

Mayor

Una funcionalidad significativa está rota o gravemente deteriorada. Existe un workaround, pero es incómodo o no obvio. Ejemplo: exportar un reporte a CSV produce un archivo con codificación garbled para cualquier nombre que contenga un carácter no ASCII.

Menor

La funcionalidad funciona, pero algo está mal de una forma que afecta la experiencia del usuario sin impedir la tarea. Ejemplo: el email de confirmación de "Restablecer Contraseña" dice "Tu contraseña as sido restablecida" en lugar de "ha sido restablecida".

Trivial

Cosmético, impacto funcional insignificante. Ningún usuario está bloqueado. Ejemplo: el año del copyright en el footer dice 2024 en lugar de 2026.

Tú, como QA, estableces la severidad. Es tu juicio profesional y debería ser defendible basado en el impacto observable, no en intuiciones.

Qué significa realmente la prioridad

La prioridad mide la urgencia de negocio. ¿Qué tan pronto necesita corregirse esto, en relación a todo lo demás en el backlog?

La prioridad no es solo tu decisión. Un product manager, un lead de ingeniería o un product owner típicamente posee la prioridad, porque requiere conocimiento del cronograma del release, compromisos de negocio y tolerancia al riesgo que QA frecuentemente no tiene visibilidad completa.

Dicho esto, tu evaluación de severidad alimenta directamente su decisión de prioridad. Si etiquetas mal la severidad, estás alimentando datos incorrectos en una decisión de negocio.

En la práctica, los equipos pequeños difuminan estas líneas. Un QA lead puede establecer ambas en un bug. Está bien. Lo clave es mantener el razonamiento separado: "esto es técnicamente malo por estas razones" versus "esto necesita salir el viernes por estas razones".

La matriz 2×2: dónde se pone interesante

Los casos obvios son fáciles. ¿Un crash del checkout en el flujo de pago principal? Alta severidad, alta prioridad, corregirlo ahora. ¿Un píxel mal alineado en una página de administrador que nadie usa? Baja severidad, baja prioridad, puede esperar.

Los casos interesantes son los dos rincones que todos se pierden.

Alta severidad, baja prioridad

Imagina que estás probando una aplicación empresarial con una funcionalidad de importación masiva de datos usada por administradores de bases de datos para migrar datos heredados. Encuentras un bug: si el archivo de importación contiene una columna con valores nulos en una posición específica, corrompe el conjunto de datos importado.

Severidad Crítica. La corrupción de datos es lo peor que hay.

Pero la funcionalidad se usa una sola vez durante el onboarding inicial por un único usuario técnico, siempre en condiciones supervisadas, y existe un workaround (eliminar los valores nulos de esa columna antes de importar). El próximo release es en un mes, y hay cinco flujos de mayor tráfico con bugs activos compitiendo por el tiempo del desarrollador.

¿Prioridad? Media, quizás incluso Baja para este sprint particular.

La severidad no cambia. La corrupción de datos sigue siendo Crítica. Pero la decisión de negocio de programarlo después que un bug Mayor en el flujo de checkout del usuario es completamente racional.

Baja severidad, alta prioridad

Tu empresa acaba de lanzar un producto co-branded con un partner importante. En la página de inicio, el nombre del partner está escrito incorrectamente. Una letra transpuesta.

¿Severidad? Trivial. Ningún usuario está bloqueado. Ningún dato está en riesgo. La aplicación funciona perfectamente.

¿Prioridad? Crítica para este release. Legal, partnerships y marketing se preocupan por esto antes de que el product manager termine su café de la mañana. Va a la cola de hotfix por delante de un bug Mayor en un flujo secundario.

Este es el caso que confunde más frecuentemente a los QA junior. Ven "severidad Trivial" y asumen baja prioridad, luego se confunden cuando se corrige en dos horas mientras su bug Mayor sigue sin tocarse.

Ejemplos reales de los cuatro cuadrantes

Alta severidad + Alta prioridad

Durante el testing de regresión, encuentras que enviar el formulario de restablecimiento de contraseña con un email válido devuelve un error 500 y el email de reseteo nunca se envía. Los usuarios están bloqueados sin ruta de recuperación. Esto sale el lunes. Corregirlo hoy.

Alta severidad + Baja prioridad

La exportación del log de auditoría de la aplicación, usada por los oficiales de cumplimiento para generar reportes trimestrales, produce un archivo malformado si el rango de fechas abarca más de 18 meses. Esto es genuinamente malo (riesgo de integridad de datos), pero el próximo ciclo de exportación es en 10 semanas, existe un workaround (ejecutar dos exportaciones y combinarlas), y el equipo de cumplimiento fue informado. Va al backlog del próximo sprint, no al actual.

Baja severidad + Alta prioridad

Tres semanas antes del lanzamiento público de la app, notas que la meta etiqueta de título en la landing page dice "Documento sin título", un placeholder de plantilla que nunca se actualizó. Cero impacto funcional. Pero aparecerá en los resultados de búsqueda de Google y en las previsualizaciones de redes sociales desde el día del lanzamiento. SEO, marketing y el CEO se preocupan. Se corrige esta tarde.

Baja severidad + Baja prioridad

El tooltip en el panel de filtros avanzados dice "Clic para epxandir" en lugar de "expandir". Lleva seis meses ahí. Se corregirá en un paso de UI el próximo trimestre. Nada de esto es urgente.

Quién establece qué, y por qué importa

Vale la pena indicar claramente la división de responsabilidad.

QA establece la severidad. Observaste el bug, probaste el impacto, sabes lo que se supone que debe hacer el sistema. Estás en la mejor posición para juzgar qué tan roto está algo técnicamente. Apropíate de esa decisión. Si un desarrollador cuestiona tu etiqueta de severidad, está preparado para explicar tu razonamiento: "Lo marqué como Crítico porque resulta en pérdida de datos en el escenario afectado, lo que por nuestras definiciones de severidad lo ubica en ese nivel."

Producto o gestión establece la prioridad. Tienen contexto que tú no tienes: qué clientes están afectados, qué compromisos existen, cuál es la presión competitiva, qué permite la capacidad del sprint. Respeta que esa es su decisión.

Dónde las cosas salen mal: QAs que ponen severidad Baja en todo para evitar conflictos, o que asumen que porque ellos lo encontraron debe ser Crítico. Ambos patrones erosionan la confianza. La severidad precisa es parte de tu output profesional, tómala en serio.

Cómo argumentar por la prioridad cuando alguien la cuestiona

Registraste un bug Mayor en un flujo central del usuario. El PM responde: "Lo veremos el próximo sprint." Tú piensas que necesita salir esta semana.

La forma de plantear este caso: enmarcarlo en impacto de usuario y de negocio, no en orgullo técnico.

Argumento débil: "Pero este es un bug Mayor, tiene que corregirse ahora."

Argumento más sólido: "Esto rompe el flujo de exportación para cualquier usuario con más de 500 ítems. Según nuestros datos de usuarios, eso representa aproximadamente el 30% de las cuentas activas. Si salimos el viernes sin corregirlo, vamos a recibir tickets de soporte. Prefiero señalarlo ahora que manejarlo post-release."

Dale al PM algo que pesar. Están tomando una compensación de riesgo. Tu trabajo es poner la información correcta sobre la mesa, no tomar la decisión final. Si escuchan el caso de negocio y aun así deciden aplazarlo, es una decisión de producto legítima. Documenta que el bug era conocido y fue triagado, regístralo y sigue adelante.

La escala de cinco niveles vs la de cuatro niveles

Algunos equipos usan cinco niveles de severidad: Crítico, Alto, Medio, Bajo, Trivial. Otros usan cuatro (Crítico, Mayor, Menor, Trivial). Algunos usan tres (Alto, Medio, Bajo).

La escala que uses importa menos que la aplicación consistente dentro de tu equipo. El problema con las escalas más grandes no es la cantidad de niveles. Es que los equipos terminan debatiendo si algo es Alto o Medio en lugar de triagear bugs. Si tu equipo pasa 20 minutos discutiendo si un bug es Menor o Trivial, la escala tiene más granularidad de la que tu proceso puede soportar.

Para la mayoría de los equipos, cuatro niveles funcionan bien. Cinco es apropiado si tienes una organización de QA grande donde la severidad alimenta timers de SLA automatizados (por ejemplo, los bugs Críticos deben ser reconocidos en 2 horas, los Altos en 24 horas). Tres niveles funcionan en equipos de etapas tempranas que se mueven rápido donde la sutileza es un lujo.

Elige una escala, documenta qué significa cada nivel con ejemplos concretos, y aplícala de forma consistente. La consistencia importa más que la precisión.

Escribir la severidad en un reporte de bug que no se discuta

La razón por la que la severidad se cuestiona en las reuniones de triage es casi siempre la misma: la etiqueta de severidad está ahí, pero el razonamiento no.

"Severidad: Crítica" invita a un debate. "Severidad: Crítica: hacer clic en Enviar descarta silenciosamente el envío del formulario sin ningún feedback; los usuarios creen que su acción tuvo éxito, pero nada se guarda" no lo hace.

Escribe la severidad como un veredicto corto con evidencia. Una o dos oraciones. Indica el impacto, indica por qué cae en ese nivel.

El patrón: [Nivel de severidad]: [qué hace mal el sistema] [quién está afectado y cómo] [por qué este nivel y no uno más bajo].

Aplicado:

Malo: Severidad: Mayor

Mejor: Severidad: Mayor. El flujo de restablecimiento de contraseña falla para todos los usuarios que intentan resetearla desde un navegador móvil. Los usuarios están bloqueados para recuperar la cuenta en móvil; el escritorio sigue funcionando, que es el workaround.

Esta redacción hace tres cosas: justifica la etiqueta con el impacto, delimita quiénes están afectados, y reconoce qué lo hace Mayor en lugar de Crítico (existe un workaround). Cualquiera que lea el ticket entiende la decisión de severidad sin necesitar que se la expliques.

Cómo aplicar esto el lunes por la mañana

Cuando registres tu próximo bug, detente en los campos de severidad y prioridad en lugar de hacer clic en la primera opción que parezca correcta.

Pregúntate: ¿qué se rompe realmente acá, y para quién? Si un usuario se encuentra con este bug, ¿puede completar su objetivo de otra manera? ¿Afecta a todos los usuarios o a un segmento específico? ¿Corrompe datos o solo incomoda a alguien?

Esa respuesta es tu severidad. Escribe una justificación de una oración junto a la etiqueta.

Luego mira el backlog de tickets. ¿Qué sale en este sprint? ¿A quién afecta este bug en relación al resto de los bugs que esperan? Redacta una sugerencia de prioridad en un comentario, no como una exigencia, sino como input: "Dado que esto afecta el flujo de pago principal y lanzamos el viernes, sugeriría hacerlo una prioridad del sprint".

Con el tiempo, esta práctica hace algo visible: tus decisiones de triage dejan de ser revertidas. Los PMs dejan de sobreescribir tus etiquetas. Los desarrolladores dejan de cuestionar tus llamadas a Crítico. No es porque tuvieras suerte. Es porque separaste dos conceptos que la mayoría de los QA junior colapsan en uno, y empezaste a comunicar la distinción con claridad.