La Distincion Critica
Severidad y prioridad son los dos conceptos mas confundidos en gestion de bugs. Confundirlos lleva a recursos mal asignados — bugs criticos se ignoran mientras issues cosmeticos reciben atencion urgente.
Severidad = Que tan grave es el impacto en el sistema? (Evaluacion tecnica) Prioridad = Que tan pronto debe corregirse? (Decision de negocio)
Estan relacionados pero son independientes. Un bug puede tener severidad alta pero prioridad baja, o viceversa.
Niveles de Severidad
La severidad es una evaluacion tecnica objetiva del impacto del bug.
Critica (S1)
Crash del sistema, perdida de datos, brecha de seguridad o falla completa de feature sin workaround.
Ejemplos:
- Aplicacion se cae al iniciar para todos los usuarios
- Procesamiento de pagos cobra tarjetas dos veces
- Datos de usuario expuestos a usuarios no autorizados
Mayor (S2)
Feature principal rota o significativamente degradada, pero el sistema no se cae. Puede existir workaround.
Ejemplos:
- Login falla para usuarios con autenticacion de dos factores
- Busqueda retorna resultados incorrectos con caracteres especiales
- Exportar a PDF genera archivos corruptos
Menor (S3)
Feature funciona pero con issues cosmeticos, problemas menores de usabilidad o fallas en edge cases.
Ejemplos:
- Formato de fecha muestra MM/DD/YYYY en lugar de DD/MM/YYYY para locale europeo
- Texto de tooltip se superpone con boton adyacente en pantallas pequenas
Trivial (S4)
Issues cosmeticos sin impacto funcional. Typos, elementos desalineados, inconsistencias visuales menores.
Ejemplos:
- Typo en footer: “Copyrite” en lugar de “Copyright”
- Color de boton es #0066CC en lugar del spec #0066FF
Niveles de Prioridad
La prioridad es una decision de negocio sobre cuando debe corregirse el bug.
P1 — Inmediata (Corregir ahora)
Debe corregirse inmediatamente. Bloquea release o causa dano activo.
P2 — Alta (Corregir este sprint)
Debe corregirse en el sprint actual. Importante para la calidad del release.
P3 — Media (Corregir proximo sprint)
Debe corregirse pronto pero puede esperar al proximo sprint.
P4 — Baja (Backlog)
Corregir cuando sea conveniente. Sin impacto de negocio inmediato.
Cuando Severidad y Prioridad No Se Alinean
Severidad Alta, Prioridad Baja
El bug es tecnicamente serio pero afecta una feature que nadie usa.
Ejemplo: Aplicacion se cae cuando usuario sube archivo de exactamente 2GB. El limite del sistema es 1GB y la UI previene subidas mayores. El crash existe pero usuarios no pueden activarlo normalmente.
Severidad Baja, Prioridad Alta
El bug es tecnicamente menor pero tiene impacto significativo de negocio.
Ejemplo: El nombre del CEO esta mal escrito en la pagina About. Tecnicamente trivial (S4), pero el CEO lo noto y es vergonzoso en reuniones con inversionistas. Prioridad: P1.
La Matriz de Prioridad
| Prioridad Alta | Prioridad Baja | |
|---|---|---|
| Severidad Alta | Corregir inmediatamente | Corregir en backlog |
| Severidad Baja | Corregir este sprint | Corregir cuando sea conveniente |
Quien Establece Que?
| Atributo | Establecido Por | Basado En |
|---|---|---|
| Severidad | QA Engineer | Evaluacion de impacto tecnico |
| Prioridad | Product Owner / Manager | Impacto de negocio, deadlines, necesidades del cliente |
Ejercicio: Clasifica Estos Bugs
Asigna severidad (S1-S4) y prioridad (P1-P4) a cada bug. Justifica tus decisiones.
- App movil se cae al rotar de portrait a landscape durante reproduccion de video
- El link de “Terms of Service” en la pagina de signup lleva a una pagina 404
- Dashboard admin muestra datos de charts con 1 hora de retraso (deberia ser en vivo)
- Notificaciones por email usan el logo viejo de la empresa (rebranding fue hace 2 meses)
- El token de password reset no expira — permanece valido indefinidamente
Solucion
1. Crash al rotar durante video: S2/P2 — Crash limitado a accion especifica 2. Terms of Service 404: S3/P1 — Riesgo legal de compliance, todos los nuevos usuarios ven signup 3. Dashboard 1 hora atrasado: S2/P2 — Decisiones de negocio dependen de datos precisos 4. Logo viejo en emails: S4/P3 — Consistencia de marca importa pero no es urgente 5. Token de reset nunca expira: S1/P1 — Vulnerabilidad de seguridad critica
Errores Comunes
- Tratar severidad y prioridad como lo mismo — miden cosas diferentes
- QA estableciendo prioridad unilateralmente — prioridad es decision de negocio
- Inflar severidad para que bugs se corrijan mas rapido — erosiona confianza
- No re-evaluar prioridad con el tiempo — un bug P3 que persiste 6 meses deberia re-priorizarse
Puntos Clave
- Severidad mide impacto tecnico (objetivo); prioridad mide urgencia de negocio (subjetivo)
- Son independientes — un bug puede ser severidad alta/prioridad baja o viceversa
- QA evalua severidad; Product Owner/Manager establece prioridad
- Prioridad se ajusta en reuniones de triage basada en contexto de negocio
- Nunca inflar severidad para manipular el sistema — destruye la credibilidad de QA