Un nombre de empresa mal escrito en la página de inicio y un fallo en una función de exportación poco utilizada: ¿qué soluciona primero? Argumentos como este son la razón por la que los equipos de pruebas separan severidad versus prioridad. Uno describe los daños técnicos y el otro describe la urgencia empresarial.

Sin esa distinción, cada error se etiqueta como “crítico”, las etiquetas pierden su significado y los desarrolladores dejan de confiar en ellos. Esta guía le brinda definiciones y ejemplos claros, junto con un proceso simple para tomar estas decisiones. Los ejemplos son ilustrativos y las escalas exactas difieren entre equipos y herramientas.

La respuesta corta

Severidad responde: ¿En qué medida afecta este error al producto? Un fallo o pérdida de datos es grave, mientras que un fallo estético no lo es.

Respuestas prioritarias: ¿cuándo debemos solucionarlo? Eso depende de los clientes afectados, los plazos, los ingresos, la exposición legal y la reputación de la marca.

Piense en un hospital. La gravedad es la gravedad de la condición del paciente. La prioridad es el orden en que se trata a los pacientes, que también depende de otros factores, como quién puede esperar de forma segura y qué recursos son gratuitos.

Gravedad versus prioridad, uno al lado del otro

Niveles de gravedad

La mayoría de los equipos utilizan alrededor de cuatro o cinco niveles. Aquí hay una escala común:

Niveles de prioridad

Escriba lo que significa cada nivel para su equipo, idealmente con un tiempo de respuesta objetivo para cada uno. “P1 significa que alguien comienza dentro de una hora” es mucho más útil que “P1 significa muy importante”.

Las cuatro combinaciones, con ejemplos.

La forma más clara de entender esto es observar cada combinación:

Alta gravedad, alta prioridad

El pago falla para todos, la empresa pierde dinero minuto a minuto y no hay solución. Este es el caso obvio: deja todo y arréglalo.

Alta gravedad, baja prioridad

La aplicación falla al exportar a un formato heredado. Técnicamente, eso es un fracaso grave. Pero si sólo una pequeña parte de los usuarios toca esta función y un formato moderno funciona bien, puede esperar hasta un lanzamiento programado.

Gravedad baja, prioridad alta

El nombre de la empresa está mal escrito en la página de inicio. No hay nada roto y ningún dato está en riesgo. Sin embargo, todos los visitantes lo ven, daña la confianza y, si mañana se prevé un lanzamiento importante, es necesario solucionarlo hoy.

Baja gravedad, baja prioridad

Un pequeño error tipográfico en un artículo de ayuda poco visitado. Arréglalo cuando sea conveniente. Si su trabajo pendiente está lleno de estos, considere agruparlos en una sola tarea de limpieza.

Un error, dos prioridades diferentes

Un mismo defecto puede merecer diferentes prioridades según el contexto. Supongamos que se envía un correo electrónico de confirmación de pedido con el logotipo incorrecto.

La gravedad no cambió porque el impacto en el sistema es el mismo. Pero la situación empresarial sí. El tiempo también puede cambiar las cosas. Un error que hoy es P3 puede convertirse en P1 la semana anterior a la entrada en funcionamiento de un cliente importante.

¿Quién decide la gravedad y la prioridad?

• Los evaluadores generalmente proponen severidad, ya que han visto el comportamiento y comprenden el impacto en el sistema.
• Los propietarios o gerentes de productos generalmente deciden la prioridad, ya que sopesan los clientes, los ingresos y la hoja de ruta.
• Los desarrolladores agregan información sobre la causa, el riesgo de una solución y cuánto tiempo llevará.
• Los equipos de soporte aportan evidencia de cuántos clientes se ven afectados y en qué medida.

Las fuentes y los equipos varían en cuanto a estas responsabilidades, y en una pequeña startup una persona puede hacerlo todo. Lo que importa es que todos sepan quién toma la decisión final, de modo que los desacuerdos terminen con una decisión.

Cómo evaluar un error

Cuando no esté seguro, resuelva estas preguntas.

Por gravedad:

1. ¿Pierde o corrompe datos, o expone información privada?
2. ¿Impide que funcione una función principal?
3. ¿Existe alguna solución? ¿Podría encontrarla un usuario normal?
4. ¿Qué parte de la característica se ve afectada?

Por prioridad:

1. ¿Cuántos usuarios se ven afectados y cuáles?
2. ¿Cuesta dinero o crea un riesgo legal o de cumplimiento?
3. ¿Se acerca un lanzamiento, una demostración o una venta?
4. ¿Qué tan visible es? ¿Podría dañar su reputación?
5. ¿Bloquea otros trabajos, como las pruebas?

Ejecución de clasificación de errores

Triage es la reunión periódica en la que un equipo revisa nuevos errores y decide qué sucede a continuación. Un formato simple funciona bien:

1. Prepárate. El evaluador se asegura de que cada nuevo error tenga pasos claros, evidencia y severidad propuesta.
2. Confirmar. Comprueba que se puede reproducir y no es un duplicado.
3. Decidir. Acordar la gravedad, establecer una prioridad y asignar un propietario.
4. Cerrar el ciclo. Rechazar, aplazar o programar cada error y registrar el motivo.

Sea breve y frecuente. Durante los últimos días antes de la liberación, es común realizar una clasificación diaria de 15 minutos. La gravedad y la prioridad también influyen en su decisión de lanzamiento, así que acuerde reglas desde el principio, como “no abrir errores S1 o S2 en el lanzamiento”, como parte de sus criterios de salida.

Gravedad y prioridad en un informe de error

Una entrada breve y clara ayuda a todos a tomar una buena decisión:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Esas cifras son ejemplos. En un informe real, utilice números medidos de sus registros y explique su razonamiento. Obtenga más información en nuestra guía sobre cómo escribir un informe de error. También es útil saber qué significan los códigos de error, así que tenga a mano nuestra hoja de referencia de códigos de estado HTTP.

Errores comunes

• Tratándolos como el mismo campo. Si los dos siempre coinciden, estás perdiendo información útil.
• Inflar la severidad para llamar la atención. Una vez que todo es crítico, nada lo es.
• Dejar que los evaluadores establezcan sus prioridades por sí solos. Rara vez tienen una visión completa del negocio.
• Nunca revisar el trabajo pendiente. Las prioridades se vuelven obsoletas, así que vuelva a verificar los errores antiguos con regularidad.
• No hay definiciones escritas. Sin ellas, las personas aplican las etiquetas de manera diferente y terminas debatiendo las palabras.
• Ignorar acumulaciones de baja gravedad. Cincuenta problemas menores pueden hacer que un producto parezca roto, incluso si ninguno es grave por sí solo.

Conclusión

Mantenga las dos preguntas separadas: ¿qué tan grave es y qué tan pronto se debe solucionar? Acuerde definiciones escritas para cada nivel y deje claro quién decide. Como siguiente paso, tome los diez errores más antiguos en su rastreador y vuelva a calificarlos usando las preguntas anteriores. Probablemente encontrará algunos que deberían moverse y otros que deberían cerrarse.

Preguntas frecuentes

sigue aprendiendo