Cuando un equipo de testing confunde severidad con prioridad, las reuniones de triage se convierten en discusiones donde gana quien habla más fuerte. Severidad y prioridad no son lo mismo, y entender la diferencia transforma un reporte de defecto en una herramienta de decisión que habla el idioma del negocio.
¿Qué mide la severidad y por qué es puramente técnica?
La severidad responde una sola pregunta: cuando el defecto se activa, ¿cuánto daño hace? Es una evaluación técnica que no depende de opiniones ni del contexto comercial. La analogía es clara: una grieta en un panel decorativo de un puente tiene severidad baja, pero la misma grieta en una viga estructural es crítica [0:44]. Mismo puente, distinta ubicación, todo cambia.
Los niveles de severidad se organizan en cuatro categorías:
- Crítica: el sistema muere por completo, nadie puede usarlo — como una app bancaria donde cada login produce un crash.
- Alta: una función importante falla pero el sistema sigue vivo.
- Media: hay fallo, pero el usuario puede completar su tarea por otro camino, con fricción.
- Baja: cosmético, por ejemplo un error de ortografía en una página interna.
¿Qué mide la prioridad y quién la decide?
La prioridad responde una pregunta completamente distinta: ¿cuánto le cuesta al negocio esperar? No es técnica, es una decisión de negocio [1:28]. La metáfora del restaurante lo ilustra bien: el horno principal está roto, problema serio, pero el servicio arranca en diez minutos y la caja registradora no procesa pagos. ¿Qué arreglas primero? La caja. El horno espera.
Los niveles de prioridad siguen esta escala:
- P0: arreglar ahora, cada hora cuesta dinero.
- P1: arreglar muy pronto, hay compromiso en riesgo.
- P2: ciclo normal de desarrollo.
- P3: cuando se pueda.
¿Por qué severidad y prioridad divergen en la práctica?
Aquí es donde se pone interesante. Un reporte anual completamente roto en una app bancaria tiene severidad alta, pero si falta meses para que alguien lo necesite, la prioridad es baja [2:04]. El equipo difiere la corrección al próximo release — decisión calculada.
El caso inverso es más difícil de justificar: un error de ortografía en la página principal de un banco nacional. Ninguna función rota, severidad baja. Pero esa página recibe millones de visitas diarias y la credibilidad se daña cada segundo. Prioridad alta. ¿Cómo defenderlo sin que la conversación se vuelva personal? Con datos: ¿cuántos usuarios ven esto?, ¿es la cara pública del producto? Los datos cierran la discusión antes de que empiece [2:31].
Una advertencia importante: nunca infles la prioridad solo para que miren tu bug más rápido. Si todo es urgente, nada es urgente.
¿Cómo funciona el ciclo de vida de un defecto?
Un defecto tiene una vida con etapas bien definidas, como un paquete en un sistema de mensajería donde cada persona que lo toca necesita una etiqueta clara [3:07]. El flujo principal sigue estos estados:
- Nuevo: el tester reporta, aún no está confirmado.
- Abierto: el líder verifica que es real.
- Asignado: alguien es responsable de corregirlo.
- En prueba: el desarrollador corrige y lo marca para verificación.
- Verificado: el tester confirma la corrección.
- Cerrado: el defecto queda resuelto.
¿Qué pasa cuando el defecto no sigue el camino feliz?
No todo defecto avanza en línea recta. Existen estados alternativos que reflejan la realidad de un proyecto [3:33]:
- Diferido: es real pero se arregla después — ahí aterriza el reporte anual roto con severidad alta y prioridad baja.
- Rechazado: no era defecto.
- Duplicado: ya existe otro reporte.
- Reabierto: la corrección no funcionó, vuelta al inicio.
¿Cómo se combinan severidad, prioridad y ciclo de vida en casos reales?
Tres ejemplos rápidos muestran cómo el sistema funciona cuando las piezas encajan [3:52]:
- Una pasarela de pagos que rechaza todas las tarjetas: severidad crítica, P0, se asigna inmediatamente.
- Un botón de exportar PDF que falla para tres usuarios internos: severidad alta, P2, espera al próximo sprint.
- El logo corporativo con colores invertidos en la página principal: severidad baja, P1, se asigna para el próximo deploy.
Severidad y prioridad apuntan en direcciones opuestas. No es contradicción — es el sistema funcionando correctamente.
El siguiente paso natural es aplicar esta misma lógica de impacto y urgencia antes de encontrar defectos: decidir qué probar primero cuando el tiempo no alcanza, usando la fórmula de probabilidad por impacto [4:32]. Si puedes justificar la prioridad de tu último defecto reportado con datos medibles — visitas, usuarios afectados, costo de espera — en vez de con opinión, ya estás hablando el idioma del negocio. ¿Lo intentas con tu próximo reporte?
