Glosario · Fundamentos de testing
Severidad de un bug
En inglés: Bug severity
También llamado: severidad del defecto, severidad de un defecto, nivel de severidad, niveles de severidad
Definición
Cuánto impacto tiene un defecto sobre el sistema o sus usuarios, desde una caída total o pérdida de datos hasta un problema estético. Suele fijarla QA.
La severidad de un bug describe cuánto afecta un defecto al producto: qué se rompe, para quién y si existe un workaround. Es un juicio técnico sobre el impacto, y normalmente la asignan los testers al reportar el bug. La severidad no dice nada directamente sobre cuándo se corregirá el bug; eso es la prioridad.
Escala típica
Los nombres varían entre equipos y herramientas, pero la mayoría usa cuatro o cinco niveles:
| Severidad | Significado | Ejemplo |
|---|---|---|
| Crítica / Bloqueante | Sistema caído, pérdida o corrupción de datos, brecha de seguridad, sin workaround | El checkout devuelve un 500 a todos los usuarios |
| Mayor / Alta | Una funcionalidad principal está rota o es incorrecta; el workaround es engorroso o no existe | Los reembolsos se calculan con el tipo de impuesto incorrecto |
| Moderada / Media | Funcionalidad parcialmente rota; existe un workaround razonable | La exportación a CSV ignora el filtro de fechas; se puede filtrar en una hoja de cálculo |
| Menor / Baja | Pequeño problema funcional con poco impacto | El orden de una lista poco usada está invertido |
| Trivial / Estética | Problema visual o de texto, sin efecto funcional | Icono desalineado, errata en un tooltip |
Severidad vs. prioridad
Severidad = impacto del defecto (técnica, la fija QA). Prioridad = urgencia de la corrección (de negocio, la fija el product owner o el triage).
Son independientes, y por eso en las entrevistas se piden ejemplos de cada combinación:
- Severidad alta, prioridad baja: la app se cae al importar un formato de archivo que un único cliente heredado usa una vez al año.
- Severidad baja, prioridad alta: el nombre de la empresa está mal escrito en la página de inicio el día antes de un lanzamiento.
- Severidad alta, prioridad alta: el pago falla para todos los usuarios.
- Severidad baja, prioridad baja: una errata en una página de ajustes que casi nadie visita.
Errores comunes
- Inflar la severidad para que corrijan un bug antes. Para eso está la prioridad. Una severidad inflada deja la métrica sin sentido.
- Valorar según lo molesto que fue encontrarlo. Valora según el impacto en el usuario y en el negocio, e indica a quién afecta y con qué frecuencia.
- Ignorar el workaround. El mismo fallo es más severo cuando no hay forma de esquivarlo.