Respuesta
Severidad mide el impacto técnico del defecto sobre el sistema: cuánto rompe. La suele proponer QA. Prioridad mide la urgencia de corrección según el negocio: cuándo hay que arreglarlo. Normalmente la define el Product Owner o el equipo, con la propuesta de QA como insumo.
Alta severidad, baja prioridad
- La app se cae al exportar un reporte en un navegador legacy que usa el 0,1% de los usuarios y que se va a dejar de soportar el mes que viene. Es un crash, pero casi nadie lo sufre.
- Un módulo interno que se usa una vez al año pierde datos en un caso borde muy raro.
Baja severidad, alta prioridad
- El logo de la empresa sale mal o el nombre de la marca tiene una errata en la home. Funcionalmente no rompe nada, pero daña la imagen y se corrige ya.
- Un texto legal mal escrito en el checkout puede tener implicancias regulatorias.
En el reporte del bug conviene justificar las dos dimensiones con datos: usuarios afectados, si existe workaround, si hay riesgo de pérdida de datos o de seguridad, y el impacto económico. Eso evita discusiones subjetivas en el triage. Las escalas varían según la empresa (Blocker/Critical/Major/Minor, P1–P4), así que hay que adaptarse a la que use el equipo.
Errores comunes
Usar los dos términos como sinónimos o decir que la prioridad siempre se deriva de la severidad. Otro error es dar ejemplos sin explicar el porqué en términos de usuarios afectados o de riesgo para el negocio.
Redactado con el asistente Underc0de IA. Actualizado el 09/11/2026. ¿Ves un error? Contanos en el foro.