En esta guía
Dos palabras se confunden todo el tiempo. Gravedad es lo malo que es el bug para el usuario: qué se rompe. Prioridad es lo pronto que lo arreglas: una decisión que también depende de cuántas personas se ven afectadas, lo fácil que es el workaround y tu fecha de lanzamiento. Un desarrollador en solitario necesita definir ambas una vez, para que el mismo bug reciba la misma calificación el lunes y el viernes.
Definiciones de gravedad (copiar y adaptar)
S1 Crítica La app se cierra, se pierden o corrompen datos, se cobra mal un pago,
o no se puede completar un flujo principal. Sin workaround.
S2 Grave Una función principal está rota o es muy difícil de usar, pero existe un workaround.
S3 Menor Una función no principal se comporta mal, o una principal en un caso límite.
S4 Trivial Cosmético: errata, desalineación, pequeño fallo visual.
Alcance (cuántos se ven afectados)
Muchos La mayoría de usuarios, o todos, en un dispositivo / SO / flujo habitual
Algunos Un grupo claramente definido (una familia de dispositivos, un idioma, un tipo de cuenta)
Pocos Condiciones raras o un único caso reportado
La matriz
Prioridad a partir de la gravedad (filas) y el alcance (columnas):
| Muchos | Algunos | Pocos | |
|---|---|---|---|
| S1 Crítica | P0: arreglar ya, parar el lanzamiento | P0: arreglar ya | P1: arreglar antes del lanzamiento |
| S2 Grave | P1: arreglar antes del lanzamiento | P1: arreglar antes del lanzamiento | P2: próxima versión |
| S3 Menor | P2: próxima versión | P2 o P3 | P3: backlog |
| S4 Trivial | P3: backlog | P3: backlog | P3: backlog, o cerrar |
Significado de las prioridades: P0 deja todo lo demás. P1 debe arreglarse antes de que salga esta versión. P2 planifícalo para la siguiente versión. P3 backlog, arréglalo cuando te quede cerca.
Plantilla para calificar un bug (copiar y pegar)
BUG: <título>
Gravedad: S<1-4> Alcance: <muchos / algunos / pocos> Prioridad: P<0-3>
Workaround: <sí: descríbelo / no>
Por qué esta calificación: <una frase>
Decisión: <arreglar ya / antes del lanzamiento / próxima versión / backlog> Fecha: <fecha>
Ejemplo (ilustrativo)
BUG: La app se cierra al guardar con un título vacío
Gravedad: S1 Alcance: Algunos (solo usuarios que dejan vacío el campo título) Prioridad: P0
Workaround: Escribir un título
Por qué esta calificación: Cierre con pérdida de datos en la acción principal de guardar; un workaround no elimina el cierre.
Decisión: arreglar ya Fecha: 2026-11-05
Cómo adaptarla
- Anula con una razón. Las reglas son para el 90 por ciento; anota por qué rompiste una.
- Sube la prioridad de los riesgos que quedan fuera de la matriz: problemas de seguridad o privacidad, errores de pago y todo lo que pueda incumplir las normas de la tienda no deben esperar. Revisa las políticas vigentes para lo último.
- Usa datos reales cuando los tengas. Los informes de fallos muestran el alcance; mira [cómo priorizar informes de fallos y [cómo priorizar el feedback de la app.
- Como máximo cuatro niveles. Más niveles significan más discusiones y no mejores decisiones.
- Explica a tus testers qué quieres decir para que sus estimaciones de gravedad coincidan con las tuyas; la decisión final sigue siendo tuya.
Relacionado
- Hub: Hub de checklists de pruebas móviles
- [Lista de problemas conocidos para testers
- [Checklist de go / no-go para el lanzamiento
Empieza gratis para recoger informes de bugs de forma estructurada y calificarlos con esta matriz.