Glosario · Fundamentos de testing
Prioridad de un bug
En inglés: Bug priority
También llamado: prioridad del defecto, prioridad de un defecto, nivel de prioridad, niveles de prioridad
Definición
Qué tan urgente es corregir un defecto frente al resto del trabajo, según las necesidades del negocio. Suele fijarla el product owner o el triage de bugs.
La prioridad de un bug describe el orden en que se corrigen los defectos. Es una decisión de negocio que sopesa el impacto en los usuarios, los plazos, los compromisos con clientes, la reputación y el coste de la corrección. Los testers pueden proponer una prioridad, pero la decisión final suele corresponder al product owner, a menudo en una reunión de triage con desarrollo y QA.
Escala típica
| Prioridad | Significado |
|---|---|
| P1 / Urgente | Corregir de inmediato; puede requerir un hotfix fuera de la release normal |
| P2 / Alta | Corregir en el sprint actual o antes de la próxima release |
| P3 / Media | Planificar para un sprint futuro |
| P4 / Baja | Corregir cuando convenga, o aceptar y cerrar |
Prioridad vs. severidad
La severidad mide el impacto: qué tan roto está el producto. La prioridad mide la urgencia: qué tan pronto hay que corregirlo. Se valoran por separado porque a menudo no coinciden.
- Severidad baja, prioridad alta: un precio incorrecto en un banner de una campaña que se lanza mañana. Nada se cae, pero tiene que estar bien antes del lanzamiento.
- Severidad alta, prioridad baja: un fallo en un informe de administración que solo se ejecuta a fin de año, dentro de once meses.
Además, la prioridad cambia con el tiempo, mientras que la severidad normalmente no. Ese mismo fallo de fin de año pasa a ser P1 en diciembre.
Cómo se decide la prioridad
Preguntas útiles durante el triage:
- ¿Cuántos usuarios se ven afectados y cuáles (clientes de pago, personal interno, un único tenant)?
- ¿Hay un workaround (solución alternativa) y puede soporte explicarlo?
- ¿Hay una release, una demo o un plazo legal o contractual?
- ¿Cuál es el coste y el riesgo de la propia corrección? Una corrección arriesgada al final de una release puede posponerse a propósito.
Errores comunes
- Usar un solo campo para ambas cosas. Los equipos que solo registran la “prioridad” pierden la información sobre el impacto, que importa para el riesgo de la release y para las métricas.
- Todo es P1. Cuando la mayoría de los bugs son urgentes, ninguno lo es. Mantén el nivel más alto como algo excepcional y bien definido.
- No revisar nunca la prioridad. Vuelve a evaluar los bugs abiertos cuando cambie el plan de releases o la situación del cliente.